<p>GRANT ... ON tenant_x. 是唯一可靠租户隔离手段，因权限检查需库表两级绑定，漏写 . 或反引号将导致授权失效；连接池须用 database= 参数而非 USE；租户账号须禁用全局权限并严格校验建库输入。</p>
GRANT ... ON <code>tenant_x.* 是唯一能真正落地的隔离手段，靠应用层拼库名、表前缀或 ORM 自动切换 schema 都不可信——权限不生效、连接复用串库、SQL 注入一击即溃。
为什么 GRANT ON *.* 或 GRANT ON tenant_x.* 漏掉 .* 就失效
MySQL 的权限检查是“库表两级绑定”，GRANT SELECT ON tenant_x（没写 .*）只给库级 USAGE 权限，连 SHOW TABLES 都被拒；必须写成 GRANT SELECT ON `tenant_x`.* 才真正授权到所有表。
- 反引号 ` 必须加：租户名含数字或短横线（如 tenant-123）时，不加会语法报错
- .* 不能省：漏写就等于没授权，应用连上后执行 SELECT * FROM users 直接报 Access denied
- 不要用 WITH GRANT OPTION：租户账号一旦拿到该权限，就能给自己加 CREATE DATABASE，直接建库撞进别人地盘
连接池里指定 database=tenant_x 比 USE tenant_x 可靠得多
USE tenant_x 是会话级命令，连接复用时极易残留旧 schema；而连接串中带 database=tenant_x（如 JDBC 的 jdbc:mysql://x:3306/?useSSL=false&database=tenant_456）能让驱动在建连时就绑定上下文。
- Druid：设 connectionInitSqls=["USE tenant_456"] 不够，得配合 initConnectionSqls + 连接获取前校验 database() 返回值
- HikariCP：没内置 init SQL 支持，必须用 ConnectionCustomizer.onAcquire() 执行 USE，且每次都要重置
- 绝对别信旧版 mysql-connector-java 的 ?database=xxx 参数：重连时大概率丢失，现象是偶发查到其他租户的同名表
租户账号必须禁用 SHOW DATABASES，但禁不了也没关系
MySQL 默认只要用户有任意库权限，SHOW DATABASES 就会列出所有库名——这不是漏洞，是设计如此。真正危险的是租户账号拥有全局权限（如 PROCESS、SHOW DATABASES 本身不算），或者应用层把库名当变量拼进 SQL。
- 正确做法：REVOKE SHOW DATABASES ON *.* FROM 'tenant_456_app'@'%'（可选，心理安慰）
- 关键动作：执行 GRANT ... ON `tenant_456`.* 后，立刻 REVOKE ALL PRIVILEGES ON *.* FROM 'tenant_456_app'@'%'，再 FLUSH PRIVILEGES
- 租户账号 host 写死子网更安全：'tenant_456_app'@'10.20.30.%'，比 '%' 少一个攻击面
建库和授权必须走白名单校验，不能拼接租户 ID
CREATE SCHEMA IF NOT EXISTS tenant_${id} 是高危操作，DDL 不支持预编译参数，只能靠应用层过滤输入。
- 白名单正则必须严格：^[a-zA-Z0-9_]{3,32}$，禁止 mysql、information_schema 等敏感词
- 建库语句必须由专用 DDL 账号执行（如 ddl_admin），该账号不能有任何租户表权限
- 示例安全语句：CREATE SCHEMA IF NOT EXISTS `tenant_abcd1234` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
- 应用启动时，用 SELECT DATABASE() 校验当前连接是否真在目标库，不匹配立即抛异常，不降级
最易被忽略的一点：权限生效不是“建完就完”，而是依赖 FLUSH PRIVILEGES（仅在直改系统表后强制需要）+ 连接重建（旧连接缓存权限状态）。线上切租户权限后，必须滚动重启应用或清空连接池，否则新权限对老连接无效。
