必须用独立数据库+独立账号+精确grant+连接串硬编码database参数，四者缺一不可；grant须写为on db_name.（反引号和.均不可省），并显式revoke show databases，jdbc连接串必须带database=xxx且禁用use切库。
直接结论：必须用独立数据库 + 独立账号 + 精确 GRANT + 连接串硬编码 database 参数，四者缺一不可。靠应用层加 tenant_id 或拼库名，等于没隔离。
GRANT 必须写成 ON `db_name`.*，不能省略 .*
这是最常被忽略的语法细节。写成 GRANT SELECT ON tenant_a TO 'u'@'%' 权限根本不会生效——MySQL 把 tenant_a 当作全局对象名，而你没授过全局权限，结果是连 USE tenant_a 都被拒绝。
正确写法：GRANT SELECT, INSERT, UPDATE ON `tenant_a_prod`.* TO 'tenant_a_app'@'10.20.30.%'
注意三点：
• 反引号 ` 必须加，尤其库名含短横线（如 `tenant-001`）
• .* 不能省，它是权限作用域的明确标识
• host 尽量不用 '%'，限制到子网更安全
必须显式 REVOKE SHOW DATABASES ON *.*
即使账号只被授予了 tenant_a_prod.* 权限，它默认仍能执行 SHOW DATABASES 并看到所有租户库名。这不是漏洞，是 MySQL 的设计行为。
补救命令只有一条：REVOKE SHOW DATABASES ON *.* FROM 'tenant_a_app'@'10.20.30.%'
别指望 REVOKE ALL 能收回这个权限——SHOW DATABASES 是独立权限项，必须单独 revoke。
MySQL 5.7 无法真正隐藏库名，只能靠这一步卡住元信息泄露入口。
JDBC 连接串必须带 database=xxx，禁用 USE 切库
很多连接池（如 HikariCP）默认不设初始库，靠运行时执行 USE tenant_x。这在多租户下极其危险：
• 连接复用时，上一个请求残留的库上下文可能影响下一个租户查询
• 某次 ORM 查询漏写库前缀（如 MyBatis 的 select * from users），就可能读到同名表的其他租户数据
正确做法：
• JDBC URL 显式写死：jdbc:mysql://host:3306/?useSSL=false&database=tenant_a_prod
• 不要用 connectionInitSqls=["USE tenant_a"] 这类兜底方案——它不解决连接复用问题
• ORM 必须配多数据源，每个租户对应独立 DataSource，禁止运行时动态切换
绝对禁止代码里拼接库名或表名
"SELECT * FROM " + tenantDb + ".orders" 看似方便，实则是高危注入点。MySQL 不校验这个字符串是否属于当前用户权限范围，只要 SQL 语法合法且账号有对应库的 SELECT 权限，就能执行成功。
真实踩坑案例：
• 备份脚本用 SHOW DATABASES 动态获取库名 → 一旦权限收不紧，就暴露全部租户库
• 应用错误地把其他租户库名写死进 SQL（如 SELECT COUNT(*) FROM tenant_b_prod.users）→ 绕过库级隔离
• ORM 配置未绑定租户库，导致 DB::table('users') 查到错误租户的数据
所有库名、表名必须来自白名单配置或初始化时静态绑定，不能由运行时变量拼接
复杂点在于：权限隔离不是一次性配置完就万事大吉的事。每次新增租户、修改账号、升级 MySQL 版本（尤其是 5.7 → 8.0），都可能触发隐性变化——比如 8.0 角色机制让 GRANT 语义更清晰，但也要求你重新梳理权限继承链；而任何一处 FLUSH PRIVILEGES 漏掉或 REVOKE 没执行，都会让整套防线出现缝隙。
