MySQL 多租户环境必须用 separate schemas 吗？
不是必须，但强烈推荐。shared schema（单库多表+tenant_id 字段）看似省事，实际在权限控制、备份恢复、数据迁移、审计合规上会持续反噬。MySQL 原生不支持行级权限隔离，
GRANT最小粒度是表或 schema，靠应用层加
tenant_id过滤属于“伪隔离”，一旦 SQL 漏写 WHERE 条件就直接越权。
实操建议：
每个租户对应一个独立schema（即
DATABASE），命名统一加前缀如
tenant_abc123禁用
CREATE DATABASE权限给租户用户，由运维脚本或平台统一创建，避免命名冲突或资源失控 不要复用
root或高权限账号连接业务应用，每个租户只授予其 own schema 的
SELECT, INSERT, UPDATE, DELETE, EXECUTE
如何用 SQL 脚本批量创建租户 schema 和用户？
手动
CREATE DATABASE+
CREATE USER+
GRANT容易出错且不可追溯。应封装为幂等脚本，支持重复执行不报错。
关键点：
用CREATE DATABASE IF NOT EXISTS避免重复建库失败
CREATE USER IF NOT EXISTS（MySQL 8.0+）或先查
mysql.user表再创建（5.7）
GRANT后必须跟
FLUSH PRIVILEGES（仅 5.7 及更早；8.0+ 在
CREATE USER/
GRANT后自动生效） 密码需用
IDENTIFIED WITH mysql_native_password BY 'xxx'显式指定认证插件，避免 8.0 默认的
caching_sha2_password导致旧驱动连不上
示例片段（MySQL 8.0）：
CREATE DATABASE IF NOT EXISTS tenant_xyz; CREATE USER IF NOT EXISTS 'app_tenant_xyz'@'%' IDENTIFIED WITH mysql_native_password BY 's3cure_p4ss'; GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE ON tenant_xyz.* TO 'app_tenant_xyz'@'%';
租户连接时如何自动路由到对应 schema？
应用不能靠写死
USE tenant_abc或拼接
tenant_abc.table_name—— 这会让 ORM、连接池、SQL 审计全乱套。正确做法是：连接串中不指定
database，由应用在建立连接后立刻执行
USE tenant_xxx，并确保该连接生命周期内只服务该租户。
注意事项：
连接池（如 HikariCP）必须关闭auto-commit外的自动 schema 切换，否则连接复用会导致跨租户污染 若用 ShardingSphere 或 Vitess 等中间件，需配置
defaultSchema或
logic-db映射，但底层仍是 per-tenant schema 禁止在存储过程中跨 schema 查询（如
SELECT * FROM tenant_a.users JOIN tenant_b.orders），这违背租户隔离原则
备份与权限审计容易被忽略的三个细节
多租户环境下，DBA 很容易只关注“能不能连上”，却漏掉权限漂移和备份盲区。
必须检查：
SHOW GRANTS FOR 'app_tenant_foo'@'%'输出是否只含
tenant_foo.*，有无意外继承了
mysql库或
performance_schema权限 物理备份（xtrabackup）是否包含所有租户 schema，
--databases参数若写死列表，新增租户会被跳过 逻辑备份（mysqldump）若用
--all-databases，会导出
mysql系统库，恢复时可能覆盖权限表 —— 应改用
--databases tenant_*模式匹配
租户数量一过百，手动维护 schema 列表和权限就不可持续，这部分必须交由配置中心或 IaC 工具驱动。
