菜鸟的成长之路——pageHelper分页插件

1.pageHelper插件在分页上有哪些优势？

分页插件给我们封装了很多参数，不用我们再去硬性编码获取各种参数。

pageHelper封装参数如下，这个参数封装在com.github.pagehelper.page中：

1. count：是否进行count查询，也就是是否进行总条数查询
2. pageNum：当前页码
3. pageSize：每页显示的数量
4. startRow：起始行
5. endRow：末行
6. total：总数
7. pages：总页数
8. reasonable：分页合理化
9. pageSizeZero：每页条数为0时是否显示所有数据
10. countColumn：进行count查询的列名
11. orderBy：排序
12. orderByOnly：只增加排序

2.pageHelper插件核心源码有哪些？

Dialect：

分页查询从两个角度，一个是分页方式，另个是数据库类型，这是所有方式和数据库类型的方法约束接口

1. skip:跳过count和分页查询
2. beforeCount:判断进行count查询还是beforePage查询，返回值为true执行count查询
3. getCountSql:生成count查询sql
4. afterCount：执行count查询后执行的逻辑
5. processParamterObject:处理查询参数对象
6. beforePage:判断进行分页查询还是返回默认结果，返回true会进行分页查询
7. getPageSql:生成分页查询sql
8. afterAll:完成所有任务后执行
9. setProperties:设置参数

AbstractDialect：

这个抽象类只为了实现一个方法，就是生成获取count的sql，这一过程是通过调用CountSqlParser来实现的。

1. getCountSql：调用了CountSqlParser的getSmartCountSql方法

AbstractHelperDialect：

物理分页方式的接口，也就是需要多少数据查找多少数据

1. processPageParamter:处理分页参数
2. getPageSql:单独处理分页部分
3. handleParamter:执行sql参数的处理

AbstractRowBoundsDialect：

逻辑分页方式的接口，将所有的数据全部查找出来，需要哪些就截取哪些，有可能会造成内存溢出的问题

1. getPageSql:生成分页查询的sql

CountSqlParser：

通过解析sql，提供更智能的sql来获取count，这个问题是分页问题的痛点,可惜的是pageHelper仍然无法避免对于count的全表扫描

1. addAggregateFunctions:向框架中添加聚合函数，避免由于聚合引起总条数查找错误，pageHelper本身已经初始化了常用的聚合函数。
2. getSmartCountSql:通过列表sql获取智能的count获取sql，如果解析失败等意外，直接调用getSimpleCountSql方法
3. getSimpleCountSql:通过列表sql一般的获取count语句
4. sqlToCount:将sql转换为count查询
5. isSimpleCount:判断是否可以使用一般的获取count语句，sql中不包含聚合、去重、列名带参数、函数，则可以使用一般的获取count语句
6. processSelectBody:处理selectBody去除order by语句
7. processPlainSelect:处理PlainSelect类型的selectBody去除order by语句
8. processWithItemsList:处理withItem去除order by语句
9. processFromItem:处理子查询去除order by语句
10. orderByHashParameters:判断order by是否包含参数，包含参数不能去除

PageMethod：

分页的方法类，pageHelper继承此类，对所有操作进行拦截操作

1. setLocalPage:设置page参数
2. getLocalPage:获取page参数
   
3. clearPage:清除本地page参数
4. count:获取任意查询方法的count总数
5. startPage:开始分页
6. offsetPage:开始分页
7. orderBy:排序
8. setStaticProperties:设置参数

3.pageHelper能避免count查询进行全表扫描吗？

通过对于pageHelper源码的学习，发现他没能解决count获取的时候全表扫描的问题，而真实开发的时候，我们一会会选择innoDB引擎的数据库，这个数据库使用count函数会进行全表扫描。

所以pageHelper没能解决这个问题挺失望的，虽然如此，但是pageHelper仍然可以解决代码臃肿的问题，仍然可以是分页插件的首选。

如果真的需要总条数的情况，也不想因为分页进行全表扫描，只能进行试错，我们直接返回前端10w或者100w或者更多的总数，只有当访问最后一页，才能返会真实条数。