分页插件PageHelper的使用及优化( 二 ) _PageHelper

说明：测试类仅2步就实现了订单列表的分页查询，使用方法请参见代码注释。
执行测试类，在log日志中将看到以下sql执行。

文章插图

从日志中可知(注意红框截图内容)：
PageHelper动态的对count方法做了2个处理。
1.findOrderByUserId方法添加_COUNT后缀。
【分页插件PageHelper的使用及优化】2.用select count(0) 替换原有sql select 查询字段，并去掉了order by排序。这是PageHelper根据业务sql做了优化，精简了sql，提高count的执行效率。
PageHelper动态的对业务sql添加了分页子句处理
演示程序使用mysql，所以在原有sql后面添加了LIMIT的分页子句。
优化从上面的日志分析，我们大致可猜到PageHelper的动态处理。在count方法部分，插件动态的生成了一个findOrderByUserId_COUNT sql 。该sql的规则也可以从PageHelper插件源代码中得到确认。

文章插图

如上截图，count方法中，countMsId通过业务sql id和countSuffix后缀拼接生成。而这个countSuffix就是_COUNT 。
接着看代码我们就不难发现，PageHelper插件会优先取工程中存在_COUNT后缀的sql，取不到则动态生成。
通过以上逻辑，我们就可以在项目中按它的规则，预先编写{业务id}_COUNT的sql，实现count分页逻辑的替换。
再回过来看我们之前的订单分页sql，from语句中使用left join和用户表关联。由于左连接在count上对order订单主表数量不产生任何影响。所以我们可以通过重写count方法，实现分页sql的优化。
原有left join sql

文章插图

重写count后的优化sql

文章插图

从优化后的sql可知，count从原有两张表变成了一张表。如果业务sql中相关表数量量比较大，或者其他join表比较多时，count优化将有比较好的效果。
最后再通过test类比较下两者的处理结果。
mapper文件新增findOrderByUserIdOpt和findOrderByUserIdOpt_COUNT sql

文章插图

Test类

@Testpublic void testFindUserOrderService(){//PageHelper分页静态类.第一个参数当前页码从1开始，第二个参数每页记录数.PageHelper.startPage(1,3);List<UserOrder> userOrders = this.orderService.findOrderByUserId();//PageInfo<T> 封装返回业务对象，构建分页列表对象PageInfo<UserOrder> pageInfo = new PageInfo(userOrders);log.info("---findOrderByUserId page, total count is {}, list is {}",pageInfo.getTotal(),JSON.toJSONString(pageInfo.getList()));PageHelper.startPage(1,3);userOrders = this.orderService.findOrderByUserIdOpt();pageInfo = new PageInfo<>(userOrders);log.info("---findOrderByUserIdOpt page, total count is {}, list is {}",pageInfo.getTotal(),JSON.toJSONString(pageInfo.getList()));}

执行结果：

文章插图

从以上日志截图中可以看到，findOrderByUserIdOpt_COUNT已经按照单表方式来统计了。
总结本文介绍了PageHelper分页插件的基本使用方法。并通过日志和代码分析，找到PageHelper count方法可以扩展优化的点。本文中的sql优化只是一个示例展示，提供一个思考的思路和方法，不做必要性讨论。项目中是否需做count优化，取决于业务场景和数据复杂性等综合因素。最后多谢能看到这里的同学，希望本文对你有所帮助。若有问题和建议，请多指正。