浅谈PageHelper插件分页实现原理及大数据量下SQL查询效率问题解决
转载：https://blog.csdn.net/baidu_38083619/article/details/82463058
前面源码分析见转载链接。
至此整个查询过程完成，原来PageHelper的分页功能是通过Limit拼接SQL实现的。查询效率低的问题也找出来了，那么应该如何解决。
首先分析SQL语句，limit在数据量少或者页数比较靠前的时候查询效率是比较高的。(单表数据量百万进行测试)
select * from user where age = 10 limit 1,10;结果显示0.43s
当where条件后的结果集较大并且页数达到一个量级整个SQL的查询效率就十分低下(哪怕where的条件加上了索引也不行)。
select * from user where age = 10 limit 100000,10;结果显示4.73s
那有什么解决方案呢？mysql就不能单表数据量超百万乃至千万嘛？答案是NO，显然是可以的。
SELECT a.* FROM USER a
INNER JOIN
(SELECT id FROM USER WHERE age = 10 LIMIT 100000,10) b
ON a.id = b.id;
结果0.53s
完美解决了查询效率问题！！！其中需要对where条件增加索引，id因为是主键自带索引。select的字段越多,字段数据量越大,速度就越慢,所以采用查询主键字段后进行关联大幅度提升了查询效率。
PageHelper想要优化需要在拦截器的拼接SQL部分进行重构，由于博主能力有限暂未实现。能力较强的读者可以自己进行重构
附上PageHelper的git地址：https://github.com/pagehelper/Mybatis-PageHelper/