PageHelper失效问题

问题出现记录：

修改代码后，出现分页失效问题，原本的代码再设置了
PageHelper.startPage(pageNum, pageSize);后只有一个mysql查询，我在原本的业务查询前，新增了其他的Mysql查询，导致原需要分页的查询失效

问题出现原因：
原本以为PageHelper是拦截当前线程下所有查询，对所有查询生效。

解决方法:

在需要查询分页的方法前，再写一个PageHelper.startPage(pageNum, pageSize);
PageHelper.startPage(pageNum,pageSize)会对紧随其后的一个查询分页生效

如果想在调用 PageHelper.startPage() 方法后，对紧随其后的查询关闭分页查询,调用 PageHelper.clearPage() 方法清空分页对象即可

PageHelper原理

PageHelper 通过拦截 MyBatis 的 SQL 语句，判断哪些查询需要进行分页处理。

当 PageHelper 拦截到一个查询语句时，它会解析该语句，提取出其中的 SELECT 子句和 FROM 子句，并将其封装成一个新的 SELECT 语句。然后，PageHelper 会在新的 SELECT 语句的末尾添加 LIMIT 子句，用来指定分页的起始行和结束行。

例如，对于如下的查询语句：

SELECT id, name, age FROM user WHERE age > 18 ORDER BY age DESC

PageHelper 会将其解析成如下的新的 SELECT 语句：

SELECT COUNT(*) FROM (SELECT id, name, age FROM user WHERE age > 18 ORDER BY age DESC) __page
SELECT id, name, age FROM user WHERE age > 18 ORDER BY age DESC LIMIT ?, ?

其中，第一个 SELECT 子句用来查询总的记录数，第二个 SELECT 子句用来查询指定页码的数据。PageHelper 会根据传入的参数，计算出 LIMIT 子句中的起始行和结束行，并将其设置到 PreparedStatement 中。

什么时候会导致不安全的分页？

PageHelper 方法使用了静态的 ThreadLocal 参数，分页参数和线程是绑定的。

只要你可以保证在 PageHelper 方法调用后紧跟 MyBatis 查询方法，这就是安全的。因为 PageHelper 在 finally 代码段中自动清除了 ThreadLocal 存储的对象。

如果代码在进入 Executor 前发生异常，就会导致线程不可用，这属于人为的 Bug（例如接口方法和 XML 中的不匹配，导致找不到 MappedStatement 时）， 这种情况由于线程不可用，也不会导致 ThreadLocal 参数被错误的使用。

但是如果你写出下面这样的代码，就是不安全的用法：

PageHelper.startPage(1, 10);
List<User> list;
if(param1 != null){list = userMapper.selectIf(param1);
} else {list = new ArrayList<User>();
}

这种情况下由于 param1 存在 null 的情况，就会导致 PageHelper 生产了一个分页参数，但是没有被消费，这个参数就会一直保留在这个线程上。当这个线程再次被使用时，就可能导致不该分页的方法去消费这个分页参数，这就产生了莫名其妙的分页。

上面这个代码，应该写成下面这个样子：

List<User> list;
if(param1 != null){PageHelper.startPage(1, 10);list = userMapper.selectIf(param1);
} else {list = new ArrayList<User>();
}

这种写法就能保证安全。

如果你对此不放心，你可以手动清理 ThreadLocal 存储的分页参数，可以像下面这样使用：

List<User> list;
if(param1 != null){PageHelper.startPage(1, 10);try{list = userMapper.selectAll();} finally {PageHelper.clearPage();}
} else {list = new ArrayList<User>();
}