多租户与数据权限专题测试

在每个 SQL 语句中手动添加 tenant_id 条件

通过 MyBatis 拦截器在运行时自动注入 tenant_id 过滤条件

为每个租户创建独立的数据库视图

在应用层对查询结果进行租户过滤

独立数据库方案的数据隔离性最强，但运维成本最高

独立 Schema 方案可以在同一个数据库实例中通过不同 Schema 实现租户隔离

共享 Schema 方案最适合租户数量庞大且单租户数据量较小的 SaaS 场景

独立数据库方案无法实现租户之间的数据共享需求

三种方案可以混合使用，例如 VIP 租户使用独立数据库，普通租户共享 Schema

Executor

ParameterHandler

StatementHandler

ResultSetHandler

使用 JSqlParser 解析和重写 SQL 语句，避免字符串拼接导致的 SQL 语法错误

对 UPDATE 和 DELETE 语句也需要添加数据权限过滤条件

在拦截器中直接修改 BoundSql 的 sql 字段来实现 SQL 重写

通过 ThreadLocal 传递当前用户的数据权限上下文（如部门 ID 列表）

数据权限拦截器的 @Order 优先级应高于多租户拦截器

从 Spring 的 ApplicationContext 中查找

从数据库配置表中读取

从 ThreadLocal 中获取当前线程绑定的数据源标识

从 HTTP 请求头中解析

在同一个 @Transactional 事务中可以切换到不同的数据源

数据源切换必须在事务开启之前完成

使用 @Transactional 时，Spring 会绑定事务开始时的数据源，后续切换无效

可以通过编程式事务（PlatformTransactionManager）在不同数据源间切换

分布式事务（如 Seata）可以解决跨数据源的事务一致性问题

在每个 Controller 方法执行完毕后清理

在 DispatcherServlet 的 finally 块中统一清理

使用 Servlet Filter 或 Spring HandlerInterceptor 的 afterCompletion 方法清理

不需要手动清理，ThreadLocal 会在线程结束时自动清理

在数据权限拦截器中判断当前用户角色，平台管理员角色不注入 tenant_id 条件，其他角色注入 tenant_id 条件

为平台管理员和租户管理员分别创建不同的 MyBatis Mapper 接口

使用 MyBatis 的 @SelectProvider 动态构建 SQL，根据角色决定是否添加 tenant_id 条件

在数据库层面创建视图，平台管理员视图不带 tenant_id 过滤，租户管理员视图带 tenant_id 过滤

平台管理员查询时临时切换到一个不带租户过滤的数据源