数据隔离最容易翻车的地方就是「漏写一条」？交给 MyBatis 自动解决！

👉这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料：

• 《项目实战（视频）》：从书中学，往事上“练”

• 《互联网高频面试题》：面朝简历学习，春暖花开

• 《架构 x 系统设计》：摧枯拉朽，掌控面试高频场景题

• 《精进 Java 学习指南》：系统学习，互联网主流技术栈

• 《必读 Java 源码专栏》：知其然，知其所以然

👉这是一个或许对你有用的开源项目

国产Star破10w的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构

RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、AI大模型、IoT物联网等功能：

• 多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro

• 微服务：https://gitee.com/zhijiantianya/yudao-cloud

• 视频教程：https://doc.iocoder.cn

【国内首批】支持 JDK17/21+SpringBoot3、JDK8/11+Spring Boot2双版本

• 真凶不是 SQL 写得太多，是「漏写一条就出事」

• 决策矩阵：哪种隔离方案适合你

• 核心思路：拦 prepare、改 AST、放 PreparedStatement

• 代码骨架：拦截器主体

• 关键算法：往 WHERE 树里插一刀

• 4 个真实生产坑，按踩到概率从高到低

• 我的判断

真凶不是 SQL 写得太多，是「漏写一条就出事」

凌晨两点告警：测试环境的订单出现在了生产看板上。复盘下来一句话——新加的 Mapper 方法忘了带env字段。

这是所有「靠业务层手写过滤条件」的方案的死穴：

• 业务层 if-tenant：人写人忘，每加一条 SQL 就多一个事故概率；

• Mapper BaseService 封装：通用方法拦得住，自定义复杂 SQL 拦不住；

• 物理分库：彻底但成本高，数据库实例翻倍。

真正的修法不是让大家更细心，是让 SQL 在出库前自动带上隔离条件——这就是 MyBatis 拦截器 + JSqlParser 的活路：拦截StatementHandler.prepare，把原始 SQL 解析成 AST，往 WHERE 子树里插一刀，再 toString 回去。业务代码不动一行，每一条 SQL 都自动带env = 'prod'。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro

• 视频教程：https://doc.iocoder.cn/video/

决策矩阵：哪种隔离方案适合你

不是所有项目都该上拦截器——先看自己在哪个象限：

为什么不直接用 MyBatis Plus？因为 Plus 的TenantLineHandler对子查询、UNION、复杂 JOIN 的支持是有边界的——一旦你的 SQL 里出现FROM (SELECT ... FROM xxx)这种嵌套，Plus 内置改写经常漏改。自己基于 JSqlParser 写一个，AST 怎么改自己说了算。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud

• 视频教程：https://doc.iocoder.cn/video/

核心思路：拦 prepare、改 AST、放 PreparedStatement

很多人疑惑：MyBatis 有query/update/prepare三种拦截点，为什么必须拦prepare？

MyBatis 的执行链：

1. 解析 mapper xml，生成BoundSql（含原始 SQL + 参数）

2. StatementHandler.prepare()调用 JDBCConnection.prepareStatement(sql)—— SQL 在这里被「钉死」

3. query/update只是执行已经准备好的PreparedStatement

关键就是第 2 步——SQL 一旦进入PreparedStatement，就再也改不动了。所以必须在prepare里改 SQL，再让它走原流程。

JSqlParser 提供两个核心能力：

• CCJSqlParserUtil.parse(sql)：把 SQL 字符串解析成Statement（AST 根）

• 修改 AST 后调用statement.toString()重新生成 SQL 字符串

整个改写过程完全在内存里发生，不下数据库，性能开销可以忽略。

代码骨架：拦截器主体

只贴关键部分——分发不同 SQL 类型到对应的改写方法：

@Component @Intercepts({ @Signature(type = StatementHandler.class, method = "prepare", args = {Connection.class, Integer.class}) }) public class DataIsolationInterceptor implements Interceptor { @Value("${spring.profiles.active}") private String env; @Override public Object intercept(Invocation invocation) throws Throwable { StatementHandler handler = (StatementHandler) invocation.getTarget(); BoundSql boundSql = handler.getBoundSql(); String originalSql = boundSql.getSql(); String newSql = injectEnvCondition(originalSql); // 反射把改写后的 SQL 写回 BoundSql MetaObject meta = SystemMetaObject.forObject(boundSql); meta.setValue("sql", newSql); return invocation.proceed(); } private String injectEnvCondition(String sql) throws JSQLParserException { Statement stmt = CCJSqlParserUtil.parse(sql); if (stmt instanceof Select) return rewriteSelect((Select) stmt); if (stmt instanceof Insert) return rewriteInsert((Insert) stmt); if (stmt instanceof Update) return rewriteUpdate((Update) stmt); if (stmt instanceof Delete) return rewriteDelete((Delete) stmt); return sql; // DDL 等不动 } }

关键算法：往 WHERE 树里插一刀

四种 SQL 改写本质都是「往 AST 加一个AND env = 'prod'」，但每种语句的挂点不同：

// SELECT / UPDATE / DELETE 通用：把原 WHERE 包成 AND private Expression appendEnvAnd(Expression originalWhere, String tableAlias) { EqualsTo envEq = new EqualsTo(); envEq.setLeftExpression(new Column( StringUtils.isNotBlank(tableAlias) ? tableAlias + ".env" : "env")); envEq.setRightExpression(new StringValue(env)); if (originalWhere == null) { return envEq; // 原 SQL 没 WHERE，直接返回 } AndExpression and = new AndExpression(); and.setLeftExpression(originalWhere); and.setRightExpression(envEq); return and; }

多表 JOIN 的关键细节——每张表都得加自己的t.env = 'prod'，不然漏了 JOIN 条件就会跨环境串数据。SQL 不强制带别名，所以代码里要兜底取「别名 → 表名」：

private Expression rewriteJoin(PlainSelect select) { Table main = (Table) select.getFromItem(); Expression where = appendEnvAnd(select.getWhere(), aliasOrName(main)); for (Join join : select.getJoins()) { if (join.getRightItem() instanceof Table joined) { where = appendEnvAnd(where, aliasOrName(joined)); } } return where; } /** 没别名就退化用表名，不要直接 alias.getName() 否则 NPE */ private static String aliasOrName(Table t) { return t.getAlias() != null ? t.getAlias().getName() : t.getName(); }

INSERT 改写要分三种 VALUES 形态——直接按SetOperationList强转会在INSERT INTO ... VALUES (...)上炸。JSqlParser 4.x 里 INSERT 的 source 类型对照：

private void rewriteInsert(Insert insert) { insert.getColumns().add(new Column("env")); StringValue envVal = new StringValue(env); Object src = insert.getSelect(); // 4.x 起 INSERT 的 source 都走 getSelect() if (src instanceof Values values) { // VALUES (...) 单行 / 多行 appendEnvToValues(values, envVal); } elseif (src instanceof PlainSelect ps) { // INSERT ... SELECT 的列表里追加常量列 ps.getSelectItems().add(new SelectItem<>(envVal)); } elseif (src instanceof SetOperationList ops) { // INSERT ... UNION/INTERSECT 的每一支都追加 ops.getSelects().forEach(s -> ((PlainSelect) s).getSelectItems() .add(new SelectItem<>(envVal))); } }

别想一行写完所有 INSERT 形态——VALUES、SELECT、UNION三类挂点不同，分支判断比强转优雅得多。

测试一下效果：

-- 原始 SQL SELECT a.username, a.code, o.org_code FROM admin a LEFT JOIN organize o ON a.org_id = o.id WHERE a.dr = 0; -- 改写后 SELECT a.username, a.code, o.org_code FROM admin a LEFT JOIN organize o ON a.org_id = o.id WHERE a.dr = 0 AND a.env = 'prod' AND o.env = 'prod';

INSERT 也改写到位：

-- 原始 INSERT INTO admin (id, username, code) VALUES (?, ?, ?); -- 改写后 INSERT INTO admin (id, username, code, env) VALUES (?, ?, ?, 'prod');

4 个真实生产坑，按踩到概率从高到低

坑 1：子查询只改了第一层（最常见）

-- 这种嵌套子查询很常见 SELECT * FROM (SELECT * FROM admin) sub WHERE sub.id = ?;

如果rewriteSelect只处理外层FROM，子查询里的SELECT * FROM admin就漏改。修法是递归下钻——遇到FromItem instanceof SubSelect就把子查询当独立 Select 再走一遍rewriteSelect。

坑 2：JOIN 表没别名（常见）

joined.getAlias().getName() // 没别名时直接 NPE

写 SQL 不强制带别名是 80% 项目的常态。代码里要兜底：没别名时用表名当 alias，或者直接用Table.getName()。

坑 3：UNION / INTERSECT 漏改（少见但破坏力大）

SELECT * FROM admin WHERE x = 1 UNION SELECT * FROM admin WHERE x = 2;

Select的selectBody在 UNION 时是SetOperationList不是PlainSelect——没单独处理就直接报 ClassCastException 或漏改其中一支。出现一次就是数据串号大事故。

坑 4：动态 SQL 里有占位符或注释（高级场景）

<select id="x"> SELECT * FROM admin <!-- this is a comment --> <if test="name != null"> AND name = #{name}</if> </select>

JSqlParser 4.x 解析带注释或 MyBatis 特殊 token 的 SQL 偶尔会异常。加 try-catch 兜底：解析失败走原 SQL 并记录告警日志，别让一条解析失败把整个接口打挂。

我的判断

数据隔离的本质问题不是「方案能不能跑」，而是「能不能保证 100% 的 SQL 都被覆盖」。业务层 if-tenant 看着轻量，但只要漏写一条就是事故；MyBatis 拦截器 + JSqlParser 把这件事下沉到 SQL 解析层——业务代码该怎么写还怎么写，事故面积一次性收敛。好的隔离方案不是没有 bug，是知道 bug 会出现在哪——然后让它根本进不了 PreparedStatement。

欢迎加入我的知识星球，全面提升技术能力。

👉 加入方式，“长按”或“扫描”下方二维码噢：

星球的内容包括：项目实战、面试招聘、源码解析、学习路线。

文章有帮助的话，在看，转发吧。 谢谢支持哟 (*^__^*）