PageHelper自动增加limit产生的数据查询问题

今天线上项目跑着跑着，老是查询不到正确的数据，后面对sql语句进行打印分析，发现有些时候mybatits就算使用了selectByPrimary也会
自动给我加上 limit ，后面查询资料发现，是我 PageHelper.startPage(1, 10); 和mybatits查询代码之间还有别的代码，分页参数和线程是绑定的，如果本次没有去查询数据，该线程去执行别的sql语句时就会自动加上limit ，具体方法请看开发者给出的说明文档。

总之，如果设置分页条件和sql查询语句之间还有别的代码的话就只能自己手动调用清除线程中分页参数缓存信息，

PageHelper.clearPage();

PageHelper 安全调用

• 使用 RowBounds 和 PageRowBounds 参数方式是极其安全的

• 使用参数方式是极其安全的

• 使用 ISelect 接口调用是极其安全的

• ISelect 接口方式除了可以保证安全外，还特别实现了将查询转换为单纯的 count 查询方式，这个方法可以将任意的查询方法，变成一个 select count(*) 的查询方法。

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

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

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

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

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

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

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

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

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

这种写法就能保证安全。

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

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