排雷日记 -- mybatisplus分页查询效率

雷区场景：仍然是某2G+2C的项目用户管理模块，比较普通的增删改查功能。近日被吐嘈打开人员列表（用户数据量在70-80万之间）展示页面超慢！有时还会请求超时。。。

 

初步排查：NetWork找到了响应慢为获取人员列表数据的接口，响应时间竟然超过了10s，看来实施的同学心态普遍都是极好了！！！然后安排了开发兄弟直接排查日志及查询脚本，确实也查到了一些关键问题，比如下面的查询脚本：

实际执行的脚本为：

select * from          
(SELECT bu.*, cp.name AS companyName, cp.id AS companyId 
FROM xxx_user bu 
LEFT JOIN xc_company_user cu ON cu.user_id = bu.user_id 
LEFT JOIN xc_company cp ON cp.id = cu.company_id 
LEFT JOIN xxx_dept bd ON bd.id = bu.dept_id 
WHERE bu.is_deleted = 0) t 
limit 0, 100;

而系统中集成了MybatisPlus框架，采用了自带的分页查询模式。所以在xml脚本中没有写入limit脚本，运行过程中mp会在脚本末尾自动附加上limit脚本。开发人员认为是该sql语句写的有问题，没有必要在外层又套了一个select t.* from的壳，认为内部的select做的是全表查询，所以修改了查询脚本为：

SELECT bu.*, cp.name AS companyName, cp.id AS companyId 
FROM xxx_user bu 
LEFT JOIN xc_company_user cu ON cu.user_id = bu.user_id 
LEFT JOIN xc_company cp ON cp.id = cu.company_id 
LEFT JOIN xxx_dept bd ON bd.id = bu.dept_id 
WHERE bu.is_deleted = 0
limit 0, 100;

实则不然，两者的执行效率相差无几

当然，从脚本功能上来讲确实是没有必要在外层重新包装select t.* from的壳，还是做了这一步优化。

那么，问题来了，单独执行脚本基本都在100ms以内，而接口总体响应时间却在10s钟左右。那问题很有可能出在业务逻辑上了，接口程序查询完sql之后又做了其它的业务逻辑处理了？我得到的答复是：没有！！！

不放心的我找到程序位置又确认了一遍，确实没有：

这就有点意思了，按照惯例还是需要跟进mp的baseMapper底层实现去分析原因了。起初也曾怀疑过是mp查询结果反序列化耗时引起的，但并没有查到相关的配置参数，而且测试了单页查询10条和500条数据响应时间差不多就打消了这个疑虑，还是查源码吧！

 

问题分析：一路漫长的调试源码（N多层嵌套），最终找到了mp的分页拦截器定义类PaginationInterceptor的intercept方法，

而sqlInfo.getSql()自动组装的查询总数据量的sql脚本竟然是：

SELECT COUNT(1) 
FROM xxx_user bu 
LEFT JOIN xc_company_user cu ON cu.user_id = bu.user_id 
LEFT JOIN xc_company cp ON cp.id = cu.company_id 
LEFT JOIN xxx_dept bd ON bd.id = bu.dept_id 
WHERE bu.is_deleted = 0;

执行了一遍竟然耗时7s钟！！！总算找到问题所在了，那么为何做一个count计算会这么慢呢，原因在于下面的几个left join，对于这种count而言，做这些left join纯粹是浪费时间啊！无语，mp的分页查询只是机械化的将原始sql脚本的select做了替换：

去掉这些无用的left join表之后，查询单表count耗时500ms。

 

解决方案： 目前只是确定了left join对count的性能损耗冗余量较大，针对该响应慢的接口做了如下优化，不使用mp自带的分页查询，单独写分页及count查询，而且优化查询方式，不再对每一页查询都做数据总量的查询，而是只在第一页和最后一页时重新查一遍总量，以节省系统开销。

优化后的接口响应时间第一页在600ms左右，第二页在100-200ms之间。

这只是目前临时的优化方案，对mp机械化的分页方式还是需要区分业务场景。