MySQL跨库访问权限必须通过GRANT语句显式授予每个库，不可直接INSERT mysql.db表；需确保用户、主机、库名（含反引号）完全匹配，且执行SHOW GRANTS FOR CURRENT_USER验证每条权限生效。
MySQL 允许跨库访问，但权限不是“开了某个开关”就自动生效的——它靠 mysql.db 系统表里的一行行记录来控制。你手动往这张表里插多条记录，确实能实现多库授权，但这是高风险操作，不推荐直接用。
为什么不能直接 INSERT INTO mysql.db
直接向 mysql.db 插入权限记录，绕过了 MySQL 的权限校验逻辑：
- MySQL 不会验证你填的
User和Host是否真实存在，也不会检查语法或反引号包裹是否正确 - 写错
Db字段（比如漏了反引号、大小写不一致、用了非法字符）会导致该条权限完全无效，且SHOW GRANTS也查不到 - 修改
mysql.db后必须执行FLUSH PRIVILEGES，否则权限不加载；而 GRANT 语句在 5.7.6+ 和 8.0 中是自动刷新的，更可靠 - 某些版本（如 8.0.16+）对
mysql.db表结构做了调整，字段含义可能变化，手写 SQL 容易出错
GRANT 语句才是唯一安全的多库授权方式
每增加一个可访问的库，就要执行一条独立的 GRANT。这不是冗余，而是 MySQL 权限模型的硬性要求：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 必须显式指定每个库名，例如
GRANT SELECT ON `orders`.* TO 'app_user'@'%' - 库名含下划线、短横或大小写时，必须用反引号包裹，否则报错
ERROR 1144 (42000): Wildcard denied for database - 通配符只在
GRANT语句中有效，且仅支持%和_，例如GRANT SELECT ON `app1_%`.* TO 'dev'@'%' - 不要写
GRANT SELECT ON app1_%. *（少反引号）或GRANT SELECT ON `app1_%`.* TO 'dev'@'localhost'（Host 不匹配线上连接方式）
如何验证多库权限已生效
别信配置文件或自己写的 INSERT，用实际用户连接后查真实权限：
- 用目标账号登录：
mysql -u app_user -p - 执行
SHOW GRANTS FOR CURRENT_USER;—— 注意是CURRENT_USER()，不是USER() - 输出里必须看到每一条你期望的
GRANT SELECT ON `db1`.*、GRANT SELECT ON `db2`.*，缺一不可 - 如果只看到其中一条，说明另一条
GRANT没执行成功，或 Host 不匹配
跨库 JOIN 失败时最常忽略的点
即使 SHOW GRANTS 显示两个库都有 SELECT 权限，JOIN 仍可能被拒绝，原因往往藏在细节里：
- 用户是
'app_user'@'192.168.1.100'，但你授的是'app_user'@'%'—— 这俩不等价，权限不互通 - 查询里用了
db1.table1 JOIN db2.table2，但db2是系统库（如information_schema），它不走mysql.db表，得单独授SELECT或换用performance_schema等受限方式 - 应用用连接池复用旧连接，新权限对已有连接不生效，需重启应用或等待连接轮换
- MySQL 8.0+ 开启了
sql_mode=STRICT_TRANS_TABLES，某些隐式跨库引用（如未带库名的表别名）会被拦截
真正起作用的永远是 mysql.db 表里的内容，但你绝不该亲手去改它。用 GRANT 写，让 MySQL 自己写进去，才是唯一可控的路径。
