PageHelper这种情况下有坑！

小咪咪 2023-09-24 14:18 106阅读 0赞

![format_png][]

#### 背景 ####

小黑最近在做一个项目，常规的`SpringBoot+Mybatis`架构，数据库使用的是`PostgreSQL`，并且有一些场景需要使用到分页查询，很自然的就使用了PageHelper这个分页工具，如果你是初学者或者还没有使用过PageHelper，可以了解一下。[PageHelper][]

到这里一切都很顺利，但是聪明如你一定猜到了，要有什么事情发生。

我需要完成一个数据权限的功能，根据每个用户的数据权限不同，控制每个用户只能查询到自己有权限的用户。

比如用户A只能访问他所在组织的数据，用户B是一个高级用户，能查询到多个组织的数据，用户C是超级管理员，能查询到所有数据等。

实现这个功能我采用的方式是在进行查询时，按照用户的权限不同，增加对应的查询条件。

比如业务方法中SQL是这样的：

select * from t_data where data_id = 1 limit 10 offset 0
    复制代码

我需要修改成：

select * from t_data where data_id = 1 and data_part in (1,2,3) limit 10 offset 0
    复制代码

这里需要强调一点，就是我不仅要对`t_data`这一张表增加条件，还要对其他很多张表加条件，并且可能每张表加的条件还不一样。

我采用了MyBatis的拦截器功能，在拦截器中统一对SQL进行处理，添加数据权限条件。

原以为一切会和我的预期一样，没想到中途踩了一个坑，让我折腾了半晚上。

以上是踩坑的背景，接下来看一下代码。

#### 代码实现 ####

我在拦截器中是这样做的。

MyBatis拦截器实现

/**
     * 数据权限拦截器
     * 拦截所有MyBatis的查询方法
     * @author 小黑说
     * @version 1.0
     */
    @Intercepts({
        @Signature(type = Executor.class, method = "query",args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
        @Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class})})
    public class DataPermissionInterceptor implements Interceptor {
    
        private static final Logger log = LoggerFactory.getLogger(DataPermissionInterceptor.class);
    
        @Override
        public Object intercept(Invocation invocation) throws Throwable {
            // 这是一个提前处理好的当前用户数据权限的集合，存放在ThreadLocal中。
            List<Condition> conditions = DataConditionHelper.getConditions();
    
            // 如果conditions为空代表该用户没有数据权限的限制，可以查询所有数据。
            if (CollectionUtils.isEmpty(conditions)) {
                return invocation.proceed();
            }
    
            Object[] args = invocation.getArgs();
            MappedStatement ms = (MappedStatement) args[0];
            Object parameter = args[1];
            RowBounds rowBounds = (RowBounds) args[2];
            ResultHandler resultHandler = (ResultHandler) args[3];
            Executor executor = (Executor) invocation.getTarget();
            CacheKey cacheKey;
            BoundSql boundSql;
            if (args.length == 4) {
                boundSql = ms.getBoundSql(parameter);
                cacheKey = executor.createCacheKey(ms, parameter, rowBounds, boundSql);
            } else {
                cacheKey = (CacheKey) args[4];
                boundSql = (BoundSql) args[5];
            }
    
            // 对当前查询语句进行数据权限增强处理
            String newSql = handleSql(boundSql.getSql());
    
            // 重新new一个查询语句对象
            BoundSql newBoundSql = new BoundSql(ms.getConfiguration(), newSql, boundSql.getParameterMappings(), boundSql.getParameterObject());
            // 把新的查询SQL放到statement里
            MappedStatement newMs = newMappedStatement(ms, new BoundSqlSqlSource(newBoundSql));
    
            for (ParameterMapping mapping : boundSql.getParameterMappings()) {
                String prop = mapping.getProperty();
                if (boundSql.hasAdditionalParameter(prop)) {
                    newBoundSql.setAdditionalParameter(prop, boundSql.getAdditionalParameter(prop));
                }
            }
            return executor.query(newMs, parameter, rowBounds, resultHandler, cacheKey, newBoundSql);
        }
    
        /**
        * 增强SQL
        */
        private String handleSql(String origSql) {
            SQLExpr sqlExpr = SQLUtils.toSQLExpr(origSql, JdbcConstants.POSTGRESQL);
            DataPermissionSelectVisitor selectVisitor = new DataPermissionSelectVisitor();
            sqlExpr.accept(selectVisitor);
            return sqlExpr.toString();
        }
    
        @Override
        public Object plugin(Object target) {
            if (target instanceof Executor) {
                return Plugin.wrap(target, this);
            }
            return target;
        }
    }
    
    复制代码

SQL增强功能

在对SQL进行增强时，我需要将原本的SQL语句解析成抽象语法树（AST），你可以理解为将SQL语句转换成一个java对象的树形结构，用Java对象表示SQL中的所有元素，如查询字段，WHERE，JOIN等，然后我再对需要添加条件的表增加数据权限条件。

解析SQL语句已经有很多成熟的工具，不用自己开发，我这里使用的阿里的`druid`包中的SQLUtils。

重点介绍我增加条件的代码。

public class DataPermissionSelectVisitor extends PGASTVisitorAdapter {
    
        private static final String TABLE_IGNORE_CHAR = "\"|'|`";
    
        @Override
        public boolean visit(SQLExprTableSource x) {
            // 数据权限条件
            List<Condition> dataConditions = DataConditionHelper.getConditions();
            if (CollectionUtils.isEmpty(dataConditions)) {
                return super.visit(x);
            }
            
            SQLName tableName = x.getName();
            String alias = x.getAlias();
            // 存放可以添加的条件sql片段
            List<String> conditionSqls = new ArrayList<>();
            for (Condition condition : dataConditions) {
                String name = tableName.getSimpleName().replaceAll(TABLE_IGNORE_CHAR, "");
                if (name.equals(condition.getTableName())) {
                    // 数据权限中的表名和当前SQL中的表名一致，则需要添加数据权限条件
                    if (!StringUtils.isEmpty(alias)) {
                        conditionSqls.add(alias.concat(".").concat(condition.buildCondition()));
                    } else {
                        conditionSqls.add(condition.buildCondition());
                    }
                }
            }
    
            if (CollectionUtils.isEmpty(conditionSqls)) {
                return super.visit(x);
            }
            SQLObject parent = x.getParent();
            // 单表查询
            if (parent instanceof SQLSelectQueryBlock) {
                SQLSelectQueryBlock query = (SQLSelectQueryBlock) parent;
                // 创建条件对象
                SQLExpr expr = buildExpr(conditionSqls);
                // 将条件对象添加到query对象中
                query.addCondition(expr);
            }
            // 联表查询
            if (parent instanceof SQLJoinTableSource) {
                SQLJoinTableSource query = (SQLJoinTableSource) parent;
                SQLExpr expr = buildExpr(conditionSqls);
                query.addConditionn(expr);
            }
            return super.visit(x);
        }
    	
       /**
        * 构建条件对象
        */
        private SQLExpr buildExpr(List<String> conditionSqls) {
            SQLExpr expr = null;
            for (String conditionSql : conditionSqls) {
                if (expr == null) {
                    expr = SQLUtils.toSQLExpr(conditionSql, JdbcConstants.POSTGRESQL);
                } else {
                    SQLExpr sqlExpr = SQLUtils.toSQLExpr(conditionSql, JdbcConstants.POSTGRESQL);
                    expr = SQLUtils.buildCondition(SQLBinaryOperator.BooleanOr, expr, true, sqlExpr);
                }
            }
            return expr;
        }
    
    }
    复制代码

只需要在拦截器中按照下面方法中使用即可。

private String handleSql(String origSql) {
        // 将SQL解析成SQLExpr对象
        SQLExpr sqlExpr = SQLUtils.toSQLExpr(origSql, JdbcConstants.POSTGRESQL);
        // 使用Visitor对象的accpet方法，增加数据权限条件
        DataPermissionSelectVisitor selectVisitor = new DataPermissionSelectVisitor();
        sqlExpr.accept(selectVisitor);
        return sqlExpr.toString();
    }
    复制代码

到这里，好像一切都很顺利，我测试了几个一些单表查询和联表查询都没有问题。

直到我测了一下一个带分页功能的查询，第一页没有问题，正常返回。

![format_png 1][]

但是，从第二页开始，出问题了。

![format_png 2][]

异常信息中我标注出了几个关键信息。

![format_png 3][]

从这个异常信息基本可以猜到，应该是SQL语句中的参数占位符和传入的参数数量不匹配导致的。

一般遇到这种问题，我第一反应是先面向网络编程一把。

![format_png 4][]

很显然，网友已经提前踩过类似的坑了。一圈找下来，基本可以肯定和我猜的一致。

接下来就debug看看吧，初步思路是看看在使用分页查询时，增加数据权限前后的SQL语句的变化。

#### debug走起 ####

对SQL进行修改的方法：

private String handleSql(String origSql) {
        // 增加条件之前
        SQLExpr sqlExpr = SQLUtils.toSQLExpr(origSql, JdbcConstants.POSTGRESQL);
        DataPermissionSelectVisitor selectVisitor = new DataPermissionSelectVisitor();
        sqlExpr.accept(selectVisitor);
        // 增加条件之后
        return sqlExpr.toString();
    }
    复制代码

那我们来debug一下看看，在增加数据权限条件之前，分页查询语句是下面这样的：

![format_png 5][]

在增加数据权限之后，分页查询语句变更了下面这样：

![format_png 6][]

什么鬼啊，怎么就剩limit了？！offset被吃了？！

![format_png 7][]

冷静一下，这个分页语句有点不对劲。

这里需要说明一下，postgreSQL的分页语句写法和MySQL的有点区别，在MySQL中分页语句的写法是：

-- MySQL分页语法
    SELECT * from tableName where  1=1 limit 10 offset 10;
    SELECT * from tableName where  1=1 limit 0 , 10;
    SELECT * from tableName where  1=1 limit 10;
    复制代码

但是postgreSQL的分页语法是这样的：

SELECT * FROM t_privilege_role limit 10 offset 10;
    SELECT * FROM t_privilege_role offset 10 limit 10;
    复制代码

乍一看好像一样，但是仔细一看是有区别的。

postgreSQL的分页语句必须有limit和offset，并且位置可以互换，官方标准是`limit ? offset ?`写法；

MySQL的分页语句可以省略offset，不省略的情况下必须是`limit`在前`offset`在后；

所以上面debug中的SQL语句的分页条件是 `OFFSET ? LIMIT ?`。

因为我使用的是`PageHelper`插件，所以这个条件是插件帮我自动添加上去的。

那回到debug中的现象，为什么offset条件没有了呢？是不是在druid的SQLUtils解析SQL的时候出问题了呢？持着怀疑态度我又debug一遍，发现在SQLUtils解析完SQL后，分页条件就已经变了。

![format_png 8][]

也就是说，SQLUtils并没有解析出`offset ? limit ?`中的`offset ?`，因为SQLUtils是按照官方标准的分页语法进行解析的。

#### PageHelper的分页能改吗？ ####

那PageHelper是怎么样来给查询语句加的分页条件呢？能不能让分页条件改成`limit ? offset ?`呢？

PageHelper增加分页条件的原理，其实也是使用了MyBatis的拦截器功能，在拦截器中根据用户设置的分页参数，添加上分页条件。

因为不同的数据库的分页语句语法存在差异，所以需要指定PageHelper使用哪个数据库的方言。我们一般会在配置文件中进行指定。

// pagehelper方言，mysql，oracle，postgresql等
    pagehelper.helperDialect=postgresql 
    复制代码

这个方言参数，最终在代码中是有一个具体的实现类。

![format_png 9][]

如上图，在PageHelper中默认对这些数据库进行了支持。我们来看一下postgreSQL的实现方式。

![format_png 10][]

可以看到，对`PostgreSqlDialect`是继承了`MySqlDialect`，并且分页参数如果起始页不是0的话，使用的是`offset ? limit ?`，我们顺便看一下`MySqlDialect`是如何实现的。

![format_png 11][]

可以看出在`MySqlDialect`中按照MySQL的语法做了实现，并且起始页不为0时采用的是`limit ?,?`语法。

由此，我姑且判断一下，应该是`pageHelper`的开发者在后期对`postgreSQL`进行支持，偷懒了一下，直接继承了`MySqlDialect`，采用了`postgreSQL`的另一种分页语法 `offset ? limit ?`。

为了证实我这个判断，我专门到pageHelper的github上去找看看有没有人提过类似的issue，你别说，还真找到了。

![format_png 12][]

有人在使用mybatis-plus时，也会因为这个分页语法的问题导致分页功能出现问题。

并且这位`outian`朋友已经提交了修改代码，在 v5.3.1版本中解决了这个问题。

#### 解决方案 ####

如果你使用的pageHelper是v5.3.1版本以下，并且使用的数据库是postgreSQL，那你就要小心了，快去检查一下是不是踩了这个坑。

那要怎么解决呢？有两个办法：

1.  升级PageHelper版本到v5.3.1+版本；
2.  自定义PostgreSqlDialect；

当然，这两种方式现在来说都很好做，升级版本我不确定会不会有什么新的问题，如果你比较大胆，可以升级一下做好功能测试；

这里主要说第二种方式，其实和上面那位解决这个问题的朋友基本一样。

首先自定义一个方言类，继承`AbstractHelperDialect`;

然后在类加载时，将这个方言类注册到`PageHelper`的方言中；

最后将这个方言配置到配置文件中`pagehelper.helperDialect=customerpostgresql`。

![format_png 13][]

官方的修复方法也是将`postgreSQLDialect`按照这种方式修改。

#### 最后 ####

最后简单总结下，使用postgreSQL数据库，在使用PageHelper做分页时，如果PageHelper的版本低于5.3.1，那么在拦截器场景下会有问题，需要通过升级或者改造postgreSQLDialect的方式解决，如果你的项目中正在使用，可以提前排查，避免出现问题。

[format_png]: https://img-blog.csdnimg.cn/img_convert/fca2d33d3b2faeb6cf458000e737011f.webp?x-oss-process=image/format,png
[PageHelper]: https://link.juejin.cn?target=https%3A%2F%2Fpagehelper.github.io%2F
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/d3e6802ba56917bd36139901736acd89.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/b5c8866d070575f6e789edf58e6bbc3a.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/06cf1e83a3a95664ba39f459cbd8dfa9.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/ae44cb43b8f99130b44bd58b34f52f69.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/1865e39111d92517826d2000c9712392.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/ce1c4ab774a89e61871608e9c39bf9b5.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/909b320c7a3920448b99f5a088841c2c.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/e7b96b31f9f65fb2ddd9c255c786f76f.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/7b23239cd99b8712f7f441cd20c06604.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/96b6d366e2420b7f3083dc88d1283a91.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/9f173efa80cdb6a99ce03e525aa43a18.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/b7886f0621b2f242110951ca61bf0a97.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/97a2c7b9937e33ca5b6dcd1c80c0ea9e.webp?x-oss-process=image/format,png