Schema隔离比表前缀更可靠，因其依托MySQL原生命名空间、权限控制和备份机制，避免应用层拼接前缀导致的数据混用风险。
为什么用 Schema 隔离租户比用表前缀更可靠
Schema 隔离本质是让每个租户拥有独立的数据库命名空间，MySQL 的 USE schema_name、权限控制、备份恢复都天然支持以 Schema 为粒度操作。而表前缀（如 t_tenant_a_users）靠应用层硬编码拼接，一旦漏写或写错前缀，数据就混了——这种 bug 很难被测试覆盖，上线后才暴露。
- MySQL 权限系统可精确到
GRANT SELECT ON tenant_123.* TO 'tenant_123_app'@'%'，租户间完全不可见对方 Schema - mysqldump 可按 Schema 单独导出：
mysqldump -u root tenant_456 > backup_t456.sql，备份/迁移不耦合 - 连接池配置中指定
database=tenant_789后，所有语句默认在此 Schema 下执行，避免每条 SQL 都要写tenant_789.users
创建租户 Schema 的安全写法（防 SQL 注入）
租户标识（如 tenant_id）若直接拼进 CREATE SCHEMA 语句，会引发严重注入风险。必须走白名单校验 + 预编译参数无法生效（DDL 不支持参数化），所以得靠应用层过滤。
- 只允许字母、数字、下划线，且长度限制在 32 字符内：
^[a-zA-Z0-9_]{3,32}$ - 禁止常见敏感词：
mysql、information_schema、performance_schema、sys - 建库语句必须用 root 或专用 DDL 账号执行，该账号不应赋予任何租户表级权限
- 示例安全调用：
CREATE SCHEMA IF NOT EXISTS tenant_abcd1234 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
连接时自动切换 Schema 的坑：init_connect 不够用
很多人想用 MySQL 的 init_connect 系统变量自动执行 USE tenant_xxx，但这个变量对 SUPER 权限用户无效，且无法动态传入租户名——它只是固定字符串。真正可行的是在应用连接池层做。
Mysql Skill 1.0.0 (3)
下载
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- Druid 连接池：配置
connectionInitSqls=["USE tenant_567"]，但必须确保每次获取连接前都重置（否则复用连接可能残留旧 Schema） - HikariCP 没有内置机制，需配合
ConnectionCustomizer在onAcquire回调里执行connection.createStatement().execute("USE " + tenantSchema) - 绝对不要依赖客户端连接串里的
?database=xxx参数，某些驱动（如旧版 mysql-connector-java）在重连时会丢失该参数
跨租户管理操作：如何安全地查所有租户的用户数
运维脚本需要聚合统计时，不能简单 SELECT COUNT(*) FROM information_schema.tables 就完事——因为租户 Schema 可能包含非业务表（如审计日志、临时表），而且 information_schema 查询本身不走权限缓存，高并发下易成瓶颈。
- 优先用已知租户列表轮询：
SELECT COUNT(*) FROM tenant_abc.users，再汇总。前提是租户列表存在中心元数据库中 - 如果必须动态扫描，过滤条件要严格：
SELECT table_schema FROM information_schema.schemata WHERE table_schema REGEXP '^tenant_[a-zA-Z0-9_]{3,32}$' - 避免在生产高峰期执行全量扫描；可提前建好物化视图（MySQL 8.0+ 支持函数索引模拟）或定时落库统计表
Schema 隔离看着简单，但租户名生成规则、连接初始化时机、跨 Schema 统计这三个点，最容易在线上出静默故障——尤其是租户名含特殊字符或连接复用后没重置 Schema，数据错乱时连错误日志都不会报。
