1. 多租户数据隔离为什么你需要 TenantLineHandler如果你正在开发一个SaaS软件即服务应用或者任何一个需要为不同客户比如不同公司、不同部门提供独立数据视图的系统那你一定绕不开“多租户”这个坎。简单来说多租户就是一套代码、一个数据库却能同时服务多个客户并且保证A客户绝对看不到B客户的数据。这听起来很美好但实现起来尤其是在数据库层面稍有不慎就是一场数据泄露的灾难。我见过不少项目初期为了图快直接在业务代码里每个SQL都手动拼接上where tenant_id ‘xxx’。刚开始可能只有几个查询还能应付。但随着业务膨胀成百上千个DAO方法、复杂的联表查询、动态SQL手动维护这些租户条件简直就是噩梦。漏加一个条件数据就串了改个字段名得全局搜索替换。更头疼的是新来的同事很容易忘记这个规则一不小心就埋下隐患。这时候MyBatis Plus 的TenantLineHandler就像一位贴心的“数据保安”。它的核心思想是“声明式数据隔离”。你不需要在每个SQL里重复劳动只需要告诉框架我的租户ID从哪里来存在数据库的哪个字段里然后框架就会在运行时自动、透明、无一遗漏地为所有相关的SQL查询加上这个过滤条件。开发者可以像写单租户应用一样专注于业务逻辑底层的数据隔离由框架默默搞定。这不仅仅是省了几行代码更是将一种容易出错的“约定”变成了一种由框架强制执行的“规则”极大地提升了代码的健壮性和可维护性。接下来我就带你从零开始手把手实现一个完整、健壮的多租户数据隔离方案并分享一些我踩过坑才总结出来的实战经验。2. 实战第一步理解 TenantLineHandler 的核心四要素要驾驭 TenantLineHandler你得先摸清它的脾气知道它有几个关键的方法需要你“填空”。这就像组装一个智能机器人你得告诉它眼睛看哪里租户ID手往哪里放数据库列哪些东西不能碰过滤的表。2.1 租户ID从哪里来——getTenantId()方法这是整个处理器的灵魂。框架在执行SQL前会调用这个方法问你“当前是哪个租户在操作” 你必须返回一个能代表这个租户的标识。在实际项目中租户ID的存储位置因架构而异。最常见、也最推荐的方式是使用ThreadLocal。为什么因为Web请求通常是每个线程处理一个用ThreadLocal可以完美地将租户信息与当前请求线程绑定线程安全且清晰。public class TenantContextHolder { // 使用ThreadLocal存储当前线程的租户ID private static final ThreadLocalString CURRENT_TENANT new ThreadLocal(); public static void setCurrentTenant(String tenantId) { CURRENT_TENANT.set(tenantId); } public static String getCurrentTenant() { return CURRENT_TENANT.get(); } public static void clear() { CURRENT_TENANT.remove(); } }那么谁来设置这个ThreadLocal的值呢通常是在拦截器Interceptor或过滤器Filter中。比如你的请求头里可能携带了一个X-Tenant-Id或者从用户的JWT Token中解析出了租户信息。Component public class TenantInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 从请求头获取租户ID String tenantId request.getHeader(X-Tenant-Id); if (StringUtils.isNotBlank(tenantId)) { TenantContextHolder.setCurrentTenant(tenantId); } else { // 也可以从Token、Session等地方获取 // 如果获取不到这里可以根据业务决定是抛出异常还是使用默认租户 throw new RuntimeException(租户信息缺失); } return true; } Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { // 请求结束后务必清理ThreadLocal防止内存泄漏和上下文污染 TenantContextHolder.clear(); } }在你的 TenantLineHandler 实现中getTenantId()方法就变得非常简单Override public Expression getTenantId() { String tenantId TenantContextHolder.getCurrentTenant(); if (StringUtils.isNotBlank(tenantId)) { // 返回一个SQL表达式这里假设tenant_id是字符串类型 return new StringValue(tenantId); // 如果是数值类型则用 new LongValue(Long.valueOf(tenantId)); } // 返回null框架可能不会添加条件具体看配置。通常建议抛出异常。 throw new RuntimeException(无法获取有效的租户ID); }注意getTenantId()方法有个boolean where参数在旧版本中用于区分条件是在WHERE子句还是其他部分如INSERT的VALUES。新版本通常简化了。你需要根据你使用的MyBatis Plus版本来调整。2.2 租户ID存在哪一列——getTenantIdColumn()方法这个方法最简单就是告诉框架你的数据库表中用来区分租户的那个字段叫什么名字。通常就叫tenant_id但也可能是company_id、org_id等保持全局统一即可。Override public String getTenantIdColumn() { return tenant_id; }2.3 哪些表不需要隔离——doTableFilter()方法不是所有表都需要租户隔离。比如系统全局表存放国家省份编码、数据字典的表所有租户共享。租户信息表本身存储租户元数据的表显然不能加tenant_id过滤。某些中间关系表在复杂的多对多关系中如果关联表本身不直接归属租户也可能需要过滤。Override public boolean doTableFilter(String tableName) { // 返回true表示忽略不过滤返回false表示需要处理添加租户条件 // 这里定义不需要租户隔离的表名列表 ListString ignoreTables Arrays.asList(sys_dict, sys_tenant, common_region); return ignoreTables.contains(tableName.toLowerCase()); // 建议统一转小写比较 }2.4 可选的配置入口——setProperties()方法这个方法用于接收在配置插件时传入的自定义参数用得相对较少。但如果你希望你的Handler更灵活比如可以从配置文件中读取忽略表的列表这里就派上用场了。private ListString ignoreTableList new ArrayList(); Override public void setProperties(Properties properties) { // 假设配置了 ignore.tablestable1,table2 String ignoreTables properties.getProperty(ignore.tables); if (StringUtils.isNotBlank(ignoreTables)) { ignoreTableList Arrays.asList(ignoreTables.split(,)); } } // 然后在 doTableFilter 中使用这个 list Override public boolean doTableFilter(String tableName) { return ignoreTableList.contains(tableName); }3. 完整配置与集成让 TenantLineHandler 生效理解了核心方法我们就要把它装配到MyBatis Plus中让它开始工作。这里需要注意MyBatis Plus的版本差异不同版本的配置方式略有不同。3.1 基于 MyBatis Plus 3.4 的配置推荐在较新的版本如3.4.0之后配置变得更加清晰。你需要添加一个MybatisPlusInterceptor拦截器并在其中加入TenantLineInnerInterceptor。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); // 1. 创建多租户拦截器 TenantLineInnerInterceptor tenantInterceptor new TenantLineInnerInterceptor(); // 2. 设置我们自定义的租户处理器 tenantInterceptor.setTenantLineHandler(new CustomTenantLineHandler()); // 3. 将多租户拦截器添加到拦截器链中。 // 注意拦截器的顺序很重要分页拦截器建议放在最后。 interceptor.addInnerInterceptor(tenantInterceptor); // 如果你还有分页插件也在这里添加 // interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }3.2 基于旧版本如3.3.x的配置如果你还在使用旧版本配置方式是通过PaginationInterceptor现在已标记为过时。Configuration public class MybatisPlusConfig { Bean public PaginationInterceptor paginationInterceptor() { PaginationInterceptor paginationInterceptor new PaginationInterceptor(); // 创建SQL解析器集合 ListISqlParser sqlParserList new ArrayList(); // 创建租户SQL解析器 TenantSqlParser tenantSqlParser new TenantSqlParser(); tenantSqlParser.setTenantHandler(new CustomTenantLineHandler()); sqlParserList.add(tenantSqlParser); // 将解析器设置给分页拦截器 paginationInterceptor.setSqlParserList(sqlParserList); return paginationInterceptor; } }强烈建议升级到新版本因为新的MybatisPlusInterceptor架构更统一功能也更强大。3.3 验证配置是否生效配置完成后怎么知道它起作用了呢最直接的方法是打开MyBatis的SQL日志。在application.yml中配置logging: level: com.your.mapper.package: debug # 将你的Mapper包路径设为debug然后执行一个简单的查询比如userMapper.selectList(queryWrapper)观察控制台输出的SQL。你会惊喜地发现生成的SQL自动加上了WHERE tenant_id ‘your_tenant_id’。对于INSERT语句它也会自动将租户ID插入到tenant_id列中。这就是框架帮你完成的“魔法”。4. 进阶场景与避坑指南基本的配置跑通了但真实项目远比这复杂。下面这几个场景是我在实际开发中真金白银换来的经验。4.1 场景一复杂查询与联表操作多租户条件下联表查询是个大坑。假设你有order表和order_item表都需要tenant_id隔离。当你进行order o left join order_item oi on o.id oi.order_id时你必须在两个表的连接条件上都加上租户过滤否则就可能查到其他租户的订单项。幸运的是TenantLineHandler 在生成SQL时会自动为所有需要过滤的表添加条件。也就是说上面的联表查询框架生成的SQL会是SELECT * FROM order o LEFT JOIN order_item oi ON o.id oi.order_id AND oi.tenant_id ‘xxx’ WHERE o.tenant_id ‘xxx’它确保了关联表之间的数据也在同一租户下这才是真正的数据隔离。避坑点在设计表结构时所有需要租户隔离的表都必须有tenant_id字段并且建立复合索引如INDEX idx_tenant_id (tenant_id, other_column)来提升查询性能。4.2 场景二手动SQL与Wrapper的使用有时候我们会写一些自定义的XML SQL或者使用QueryWrapper来构造复杂条件。TenantLineHandler 还能生效吗对于XML中的手写SQL默认情况下TenantLineHandler不会处理你写在XML里的原生SQL。因为框架无法安全地解析和修改这些语句。对于这种情况你有两个选择手动添加条件在XML SQL中自己加上AND tenant_id #{tenantId}并通过参数传入tenantId。使用SqlParser注解旧版或InterceptorIgnore注解新版这是一个更危险的操作它告诉框架忽略某条语句的租户过滤。请极度谨慎使用仅用于超级管理员或确实需要跨租户操作的场景并且要做好权限校验。// 新版 MyBatis Plus 忽略租户过滤的写法在Mapper方法上 InterceptorIgnore(tenantLine true) ListUser selectAllTenantData();对于QueryWrapper这是最友好的方式。你正常使用QueryWrapper构造条件框架会在最后生成SQL时自动在WHERE子句的最前面加上租户条件。你完全不需要在Wrapper中操心tenant_id。4.3 场景三数据初始化与超级管理员系统初始化时或者需要一个超级管理员角色来管理所有租户的数据时我们可能需要“绕过”租户过滤。一种常见的做法是在调用这些特定服务的方法前在代码层面“暂时清空”租户上下文。但更优雅的方式是利用MyBatis Plus的“忽略租户过滤”功能。你可以创建一个“系统上下文”工具类在执行需要跨租户的操作时动态地让TenantLineHandler返回一个“忽略”标识或者直接配置一个不添加条件的Handler。但更简单的做法是将这些特殊的操作放在独立的Service或Mapper方法中并使用上面提到的InterceptorIgnore(tenantLine true)注解。关键是要有严格的权限控制确保只有极高权限的账号或系统内部任务才能调用这些方法。4.4 场景四性能考量与最佳实践自动化的东西虽好也要关注性能。索引是生命线务必为tenant_id字段以及tenant_id 常用查询字段建立复合索引。99%的多租户查询都是带租户条件的没有索引会导致全表扫描性能灾难。谨慎使用doTableFilter只将真正全局的、不需要隔离的表放入忽略列表。不要因为一时方便而扩大忽略范围。租户ID的生成租户ID本身的设计也很重要。使用分布式ID生成器如雪花算法避免使用自增ID以防泄露业务数据量信息。同时ID类型最好与数据库字段类型匹配字符串或数字。测试测试再测试多租户的BUG往往是数据层面的、严重的。必须编写全面的单元测试和集成测试模拟不同租户的并发操作确保数据绝对隔离。5. 从设计到落地一个完整的微服务多租户方案设想TenantLineHandler解决了数据访问层的隔离但要构建一个健壮的SaaS应用你还需要一个顶层设计。这里我分享一个我们在中型项目中采用的方案供你参考。核心思想租户上下文贯穿请求生命周期。网关层用户请求到达API网关如Spring Cloud Gateway。网关从JWT Token或请求头中提取租户标识可能是租户ID也可能是租户的唯一域名。传递租户信息网关将租户标识放入请求头如X-Tenant-Id转发给下游微服务。微服务入口每个微服务通过一个全局的Filter或HandlerInterceptor拦截请求从请求头中取出X-Tenant-Id并将其设置到当前线程的TenantContextHolder即我们前面定义的ThreadLocal工具类中。数据访问层此时MyBatis Plus的TenantLineHandler的getTenantId()方法就能从TenantContextHolder中无缝获取到租户ID并自动注入SQL。异步任务与消息队列这是难点。当你在业务中启用了新线程如Async或发送消息到MQ时ThreadLocal会失效。解决方案是异步任务在执行异步方法前将TenantContextHolder中的值作为参数显式传递进去或者在任务开始时重新设置。消息队列在发送消息时将租户ID作为消息的一个属性Header一起发送。消费者在消费消息时首先从消息属性中取出租户ID并设置到自己的TenantContextHolder中然后再执行业务逻辑。清理在Filter或Interceptor的afterCompletion方法中必须调用TenantContextHolder.clear()来清理ThreadLocal防止内存泄漏和后续请求被错误的数据污染。这个方案确保了从请求入口到数据库访问再到异步环节租户上下文像一条线一样贯穿始终实现了端到端的数据隔离。TenantLineHandler 在这个体系中完美地承担了数据访问层“自动门卫”的职责让业务开发者几乎感知不到多租户的存在可以更纯粹地关注业务逻辑实现。