不能直接用CREATE DATABASE app1_db完事，因MySQL不识别前缀，需创建专用账号并授权app1_%.*（8.0.17+支持），禁用GRANT OPTION，配合连接层路由限制与严格sql_mode防误操作。
给应用分配独立数据库时，为什么不能直接用 CREATE DATABASE app1_db 就完事？
因为权限粒度会失控：一个应用误删了另一个应用的库、备份脚本顺手清掉所有前缀匹配的库、甚至开发连错环境执行了 DROP DATABASE。前缀命名（如 app1_、app2_）只是组织习惯，MySQL 不识别“前缀”这个概念，它只认具体库名和用户权限规则。
实操建议：
- 先创建专用账号，例如
CREATE USER 'app1_rw'@'%' IDENTIFIED BY 'pwd'; - 只授权明确的库：
GRANT SELECT, INSERT, UPDATE, DELETE ON `app1_%`.* TO 'app1_rw'@'%';—— 注意反引号包裹通配符库名，且必须用`app1_%`而不是app1_%，否则报错ERROR 1144 (42000): Wildcard denied for database - 禁止授予
GRANT OPTION，避免权限扩散
GRANT ... ON `app1_%`.* 真的能拦住跨库操作吗？
能，但有前提：MySQL 8.0.17+ 才支持数据库级通配符授权；5.7 及更早版本不支持 `app1_%` 这种写法，会直接报错。即使支持，也仅限于显式指定的语句（如 SELECT FROM app1_users），对跨库 JOIN 或临时表无约束力。
常见错误现象：
- 应用代码里写了
SELECT * FROM app2_logs WHERE id IN (SELECT id FROM app1_events)，权限检查通过了——因为app1_events在授权范围内，但逻辑上不该读app2_logs - 用
mysqldump --databases app1_auth app1_api备份时，如果用户没被单独授予app1_api库，dump 会失败，哪怕两个库都匹配`app1_%`
所以通配符授权是「最小必要库范围」的起点，不是隔离终点。
如何防止应用连错库却仍能执行危险操作？
靠账号绑定库名前缀 + 连接参数硬限制。MySQL 本身不提供“只允许访问以某前缀开头的库”的运行时策略，得从客户端和中间层卡住。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 在应用配置里固定
database参数为具体库名（如app1_main），而非留空或填通配符 - 用 MySQL Router 或 ProxySQL 做路由层拦截：配置规则，拒绝任何目标库名不匹配
^app1_的连接请求 - 启用
sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，避免因表不存在自动创建新库（某些 ORM 会触发） - 定期用
SELECT user, host, db FROM mysql.db WHERE db LIKE 'app1\_%' ESCAPE '\';检查实际生效的库级权限是否漂移
为什么 REVOKE ALL ON *.* FROM 'app1_rw'@'%' 后权限没清干净？
因为 MySQL 权限分层级，ON *.* 只撤销全局权限（如 CREATE USER），不影响已存在的数据库级权限（ON `app1_%`.*）。这是最容易忽略的断层点：以为“全 revoke”就安全了，其实 SHOW GRANTS FOR 'app1_rw'@'%' 还能看到残留的库级授权行。
正确清理方式：
- 先查清楚有哪些库级授权：
SELECT db, user, host FROM mysql.db WHERE user = 'app1_rw'; - 逐条撤销：
REVOKE ALL PRIVILEGES ON `app1_%`.* FROM 'app1_rw'@'%'; - 最后再
DROP USER 'app1_rw'@'%';彻底删除账号
通配符库名的权限不会自动随库删除而消失，也不会被 FLUSH PRIVILEGES 清除——它存的是字符串匹配规则，不是实时快照。
