已解决当前问题，可查看：

https://createdpro.com/a?id=9f8db8ef684b4ca4a3c51d4a2d671cff

-----------------这里是分割线-----------------

今进行如下业务时，发现PageHelper的分页功能突然不生效：

// 查询前10条数据
PageHelper.startPage(0, 10);
// 查询语句
XXXMapper.selectByExample(XXExample);

查询结果：

[1],[2],[3],[4],[5],[6],[7],[8],[9],[10]

接下来查询下一页：

// 查询前第10-20的数据
PageHelper.startPage(1, 10);
// 查询语句
XXXMapper.selectByExample(XXExample);

查询结果：

[1],[2],[3],[4],[5],[6],[7],[8],[9],[10]

再查询下一页：

// 查询前第20-30的数据
PageHelper.startPage(2, 10);
// 查询语句
XXXMapper.selectByExample(XXExample);

查询结果：

[11],[12],[13],[14],[15],[16],[17],[18],[19],[20]

结论：

PageHelper.startPage的第一个参数pageNum有Bug，不同于Mysql语句中LIMIT后面的两个参数：

Mysql语句中——LIMIT 0,10代表从第0项开始查询，查询10条数据

PageHelper.startPage中——(0,10)代表从第0页开始查询一页，每页10条数据。(1,10)代表从第1页开始查询一页，每页10条数据。

这时我们发现第1页的数据与第0页相同，查询的都是第一页的数据（BUG所在）

BUG分析：本质上对于PageHelper.startPage来讲，参数的意义就是按照起始页为第”1“页来计算的，只不过参数并没有对第”0“页进行限制，导致其可以搜索出与第”1“页一样的结果。

问题分析：

这个问题一度困扰我，导致查询的数据不准确。究其原因，还是将分页插件的PageHelper.startPage中的参数与Mysql语句中LIMIT的参数相混淆了，在此踩坑。