浅析PageHelper踩坑：不安全分页导致的问题

Posted 2021-08-29 古兰精

　　这个问题的起因是后端日志经常有一个报错：Error querying database. Cause: org.postgresql.util.PSQLException: ERROR: syntax error at or near "LIMIT"。

　　但是奇怪的是那个查询方法根本就没有 limit，其次不清楚原因。后来才清楚为什么，因为我们使用了 分页插件 PageHelper，在使用 PageHelper 的时候如果不注意，就会导致不安全的分页问题。

一、结论先行

　　主要原因：PageHelper 使用了静态的 ThreadLocal 参数，让线程绑定了分页参数， 这个参数如果没被使用就会一直留在那儿，当这个线程再次被使用时，就可能导致不该分页的方法去消费这个分页参数，这就产生了莫名其妙的分页。

二、造成原因：

　　什么时候会导致不安全的分页？ PageHelper 方法使用了静态的 ThreadLocal 参数，分页参数和线程是绑定的。

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

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

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

PageHelper.setPage(1,10);
if(param!=null){
    list=userMapper.selectIf(param)
}eles{
    list=new ArrayList<User>();
}

　　这样子如果 param 没有消费到，那么接下来如果进去了其他方法使用了 select 方法就会将这个page参数带进去，被消费；

　　如何改进呢？

if(param!=null){
    PageHelper.setPage(1,10);
    list=userMapper.selectIf(param)
}eles{
    list=new ArrayList<User>();
}

　　避坑：让这个分页参数紧跟查询，可以查就建立；也就是保证被消费；或者在 finally 调用 PageHelper.clearPage(); 清除。

　　这种写法就能保证安全。如果你对此不放心，你可以手动清理 ThreadLocal 存储的分页参数，可以像下面这样使用：

List<Country> list;
if(param1 != null){
    PageHelper.startPage(1, 10);
    try{
        list = countryMapper.selectAll();
    } finally {
        PageHelper.clearPage();
    }
} else {
    list = new ArrayList<Country>();
}
// 这么写很不好看，而且没有必要

三、其他问题介绍

　　最近在项目中频繁出现 sqlException，报错有两种情况，一种是拼接了order by ‘column’，一种是拼接了limit ‘num’；奇怪的是我的sql语句中并没有这些参数。

1、error1：在这里出现了未识别的字段

2、error2：sql语句中已经写了limit，pagehelper又拼接了一次，出现 \'limit 1 limit 10’的情况；

　　通过百度，了解到PageHelper使用了静态的ThreadLocal参数，分页参数和线程是绑定的；当分页参数没有被消费时，会一直存在threadlocal中，在下一次执行的sql中会拼接这些参数。

　　那么怎么避免这种情况：分页参数紧跟 list 查询。如果先写分页，又写了别的判断逻辑，没有执行 list 查询时，那么分页参数就会在threadlocal中，下次执行sql会消费这些参数，就会导致“不安全分页”。