pageHelper插件在分页上有哪些优势?
分页插件给我们封装了很多参数,不用我们再去硬性编码获取各种参数。
pageHelper封装参数如下,这个参数封装在com.github.pagehelper.page中:
- count:是否进行count查询,也就是是否进行总条数查询
- pageNum:当前页码
- pageSize:每页显示的数量
- startRow:起始行
- endRow:末行
- total:总数
- pages:总页数
- reasonable:分页合理化
- pageSizeZero:每页条数为0时是否显示所有数据
- countColumn:进行count查询的列名
- orderBy:排序
- orderByOnly:只增加排序
pageHelper插件核心源码有哪些?
Dialect:
分页查询从两个角度,一个是分页方式,另个是数据库类型,这是所有方式和数据库类型的方法约束接口
- skip:跳过count和分页查询
- beforeCount:判断进行count查询还是beforePage查询,返回值为true执行count查询
- getCountSql:生成count查询sql
- afterCount:执行count查询后执行的逻辑
- processParamterObject:处理查询参数对象
- beforePage:判断进行分页查询还是返回默认结果,返回true会进行分页查询
- getPageSql:生成分页查询sql
- afterAll:完成所有任务后执行
- setProperties:设置参数
AbstractDialect:
这个抽象类只为了实现一个方法,就是生成获取count的sql,这一过程是通过调用CountSqlParser来实现的。
- getCountSql:调用了CountSqlParser的getSmartCountSql方法
AbstractHelperDialect:
物理分页方式的接口,也就是需要多少数据查找多少数据
- processPageParamter:处理分页参数
- getPageSql:单独处理分页部分
- handleParamter:执行sql参数的处理
AbstractRowBoundsDialect:
逻辑分页方式的接口,将所有的数据全部查找出来,需要哪些就截取哪些,有可能会造成内存溢出的问题
- getPageSql:生成分页查询的sql
CountSqlParser:
通过解析sql,提供更智能的sql来获取count,这个问题是分页问题的痛点,可惜的是pageHelper仍然无法避免对于count的全表扫描
- addAggregateFunctions:向框架中添加聚合函数,避免由于聚合引起总条数查找错误,pageHelper本身已经初始化了常用的聚合函数。
- getSmartCountSql:通过列表sql获取智能的count获取sql,如果解析失败等意外,直接调用getSimpleCountSql方法
- getSimpleCountSql:通过列表sql一般的获取count语句
- sqlToCount:将sql转换为count查询
- isSimpleCount:判断是否可以使用一般的获取count语句,sql中不包含聚合、去重、列名带参数、函数,则可以使用一般的获取count语句
- processSelectBody:处理selectBody去除order by语句
- processPlainSelect:处理PlainSelect类型的selectBody去除order by语句
- processWithItemsList:处理withItem去除order by语句
- processFromItem:处理子查询去除order by语句
- orderByHashParameters:判断order by是否包含参数,包含参数不能去除
PageMethod:
分页的方法类,pageHelper继承此类,对所有操作进行拦截操作
- setLocalPage:设置page参数
- getLocalPage:获取page参数
- clearPage:清除本地page参数
- count:获取任意查询方法的count总数
- startPage:开始分页
- offsetPage:开始分页
- orderBy:排序
- setStaticProperties:设置参数
pageHelper能避免count查询进行全表扫描吗?
通过对于pageHelper源码的学习,发现他没能解决count获取的时候全表扫描的问题,而真实开发的时候,我们一会会选择innoDB引擎的数据库,这个数据库使用count函数会进行全表扫描。
所以pageHelper没能解决这个问题挺失望的,虽然如此,但是pageHelper仍然可以解决代码臃肿的问题,仍然可以是分页插件的首选。
如果真的需要总条数的情况,也不想因为分页进行全表扫描,只能进行试错,我们直接返回前端10w或者100w或者更多的总数,只有当访问最后一页,才能返会真实条数。
作者:积书网熊叔 更多免费学习资源尽在#积书网www.jeacher.com