Mybatis分页插件PageHelper使用性能方面的疑问

Question

先说一下基本情况

Mybatis分页插件PageHelper的用法，如下所示：

// 步骤1. 查询数据库获取所有的数据
List<Product> list = productMapper.selectAll();
// 步骤2. 设置页码、每页条数
PageHelper.startPage(pageNum,pageSize);
// 步骤3. 分页
PageInfo<Product> pageInfo = new PageInfo<Product>(list);

而通过查找资料和部分源码，已知：

PageHelper分页主要是通过Aop来实现，其先查询获取总的条数count，然后再执行分页sql（在这之前会在sql语句中拼接limit offset这两个参数，以此执行动态分页）。

问题：

1、这个插件不是通过SQL查询来完成的物理分页吗？为什么还需要代码中的步骤1？我没看完源码的整个工作流程，这一点不懂！
2、如果每次分页都需要步骤1 ，那数据量大的时候（几百万条以上），那性能不是会很差吗？占用的内存也是个问题吧？如果是这样，PageHelper插件却依然如此受欢迎，那它是适合运用于什么场景呢？

还望各位大佬指教，谢谢！

Answer 1

首先，你的步骤可能有点问题。正常的使用逻辑应该是先设置分页参数，再执行sql，最后完成分页。

1. PageHelper.startPage(pageNum,pageSize);
2. List<Product> list = productMapper.selectAll();
3. PageInfo<Product> pageInfo = new PageInfo<Product>(list);

所以基于你的问题：

1. 这个插件是在PageHelper设置完成后，对于之后的sql会拼接 limit start,length,所以是已经在数据库里完成了分页。所以并不会每次查询完所有的数量，因此效率也还可以。并且会在你执行sql前,执行select count(0) from ...语句查询总数量。
2. 受欢迎的原因就是很简单易用，但是对于一些相对复杂逻辑。例如你查询得到list，需要对这个list再加工，得到一个新的结果集，那么你之前的分页数据就会失效。而且，如果你在一个service业务中有多条查询，你可能需要注意PageHelper的位置。所以一般用于较为简单的查询，可以直接返回sql结果集的那种。

Answer 2

先查搜索再分页太过分了吧…官方说明完全没提到过这种啊…