必须用 separate schemas，且只读账号不能跨 schema 查询——这是唯一能防止测试数据互相污染的底线，因为 shared schema + tenant_id 过滤在测试环境不可靠：开发易漏条件、GUI 工具直查越权、ORM/SQL 客户端绕过过滤、权限无法行级控制、审计缺失、CI/CD 断言被污染。
必须用 separate schemas，且只读账号不能跨 schema 查询——这是唯一能防止测试数据互相污染的底线。
为什么不能用 shared schema + tenant_id 过滤做测试环境？
测试环境不是生产环境，但更需要强隔离：开发常写 SELECT * FROM user 忘加 WHERE tenant_id = ?，或用 GUI 工具直接点开表看数据。shared schema 模式下，这类操作天然越权。MySQL 的 GRANT 最小粒度是表或 schema，不支持“只允许查 tenant_id = 'abc' 的行”，应用层过滤在测试阶段根本不可信。
- 测试脚本、ORM 自动生成的查询、数据库客户端直连都绕过 tenant_id 过滤
- CI/CD 中的集成测试若共用库，一个租户的脏数据会污染另一个租户的断言结果
- 无法审计“谁查了谁的数据”，日志里只有
SELECT * FROM user，没 tenant_id 上下文
如何创建租户只读账号并绑定到独立 schema？
每个租户对应一个 tenant_XXX schema，只读账号命名统一为 ro_tenant_XXX，权限严格限定在单个 schema 内。关键点不是“能不能读”，而是“能不能意识到自己读的是谁的”。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 建库用
CREATE DATABASE IF NOT EXISTS tenant_abc;，避免重复执行失败 - 建用户必须用
CREATE USER IF NOT EXISTS 'ro_tenant_abc'@'%' IDENTIFIED WITH mysql_native_password BY 'r0abc123';（显式指定插件，兼容旧驱动） - 授权只给
SELECT和SHOW VIEW：GRANT SELECT, SHOW VIEW ON tenant_abc.* TO 'ro_tenant_abc'@'%'; - 禁止
USAGE或全局权限——哪怕只是SELECT也不许跨库
连接串和 ORM 怎么避免误切库或拼错 schema？
连接串里绝对不要带 database= 参数。否则 HikariCP、Druid 等连接池会在连接复用时残留 USE 语句上下文，导致后续请求查错 schema。
- 应用启动后，在获取连接的第一时间执行
USE tenant_abc;（MyBatis-Plus 可用DataSourceProxy拦截器统一注入） - 禁止在 SQL 里写
tenant_abc.user这种全限定名——它会让 MyBatis 的@Select注解失效，也让 Flyway 迁移脚本无法复用 - 测试容器（如 Testcontainer）启动 MySQL 后，用初始化脚本自动创建所有
tenant_*库和ro_tenant_*用户，而不是靠测试代码动态建
容易被忽略的三个硬伤点
测试环境最容易翻车的地方，往往不在建库建用户，而在权限生效边界和工具链适配。
-
FLUSH PRIVILEGES在 MySQL 8.0+ 不需要执行，但很多团队抄旧脚本仍加这句——它不报错，但会掩盖权限未生效的真实问题 - DBeaver、Navicat 等工具默认开启“自动提交”和“自动 USE”，必须手动关掉，否则右键“查询表”会直连
information_schema或默认库 - Spring Boot 的
spring.sql.init.schema-locations若指向通用 DDL，需确保每个tenant_XXX库都单独执行一遍，不能只跑一次再复制表结构——否则ro_tenant_abc对tenant_def的表也有隐式访问路径
