分页查询接口优化

背景

业务中一个简单查询接口耗时25s+,排查日志发现20s都浪费在一句mybatis-plus自动生成的count sql上，原来采用mybatis-plus 的分页插件
编写的分页查询方法会自动在查询sql执行之前执行一句目标查询方法_mpCount，该方法简单的将原来的查询结果作为子查询，外面包了一层
slect count(*) from (目标sql)

select * from data_file d
        left join permission p
        on d.permission_group_id = p.permission_group_id
        WHERE  d.file_name LIKE CONCAT('1','%') 
        group by d.id
        ORDER BY  create_time   
        desc LIMIT 10;

问题分析

当遇到查询结果很多时或是一些复杂查询该sql会把所有结果全部查出来进行计数，比目标sql的执行速度慢很多，因此考虑优化count SQL，禁用mybatis-plus的自动
count SQL，手动写mapper查询total

// 禁用自动count sql
page.setSearchCount(false);

// 手动count
page.setTotal(baseMapper.selectByConditionAndIdsAndUser_COUNT( request, null, userInfo));

优化后的count SQL

count SQL 目的是为了计算分页的总页数，因此只要自定义的sql计算出的比实际的大，不会影响实际使用，因此去除连表条件，
优化后的sql如下,

select * from data_file d
        WHERE  d.file_name LIKE CONCAT('1','%') 
        group by d.id
        ORDER BY  create_time   
        desc LIMIT 10;