浅谈PageHelper插件分页实现原理及大数据量下SQL查询效率问题解决

浅谈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/