MySQL 跨库 JOIN 时提示 ERROR 1142 (42000): SELECT command denied
权限不足不是因为没给单库权限，而是 MySQL 默认不允许多库联合查询——哪怕你对两个库都有 SELECT 权限，只要语句里出现 db1.table1 JOIN db2.table2，就可能被拦住。
根本原因是：MySQL 的权限是按「对象层级」检查的，SELECT 权限授予的是「某个库下的某张表」，而跨库 JOIN 实际触发了对两个库下不同表的访问，必须分别授权。
- 确认当前用户对两个库都拥有
SELECT权限：SHOW GRANTS FOR 'user'@'host'; - 如果只看到
GRANT SELECT ON `db1`.* TO ……，那db2的权限就是缺失的，得补上 - 不要试图用
GRANT SELECT ON *.*临时绕过——生产环境严禁全局权限 - 注意主机名匹配：
'user'@'localhost'和'user'@'%'是两个不同账号，权限不互通
给用户同时授予两个库的 SELECT 权限（标准操作）
必须显式、分别授予每个库，不能靠通配符或“继承”。MySQL 不认为“有 db1 权限就该能碰 db2”，它认的是字面路径。
例如要让 app_user 能查 orders 库和 customers 库：
GRANT SELECT ON `orders`.* TO 'app_user'@'%'; GRANT SELECT ON `customers`.* TO 'app_user'@'%'; FLUSH PRIVILEGES;-
FLUSH PRIVILEGES不是总需要，但改完权限后执行一次最稳妥（尤其在非 root 用户下修改时） - 如果表名含特殊字符或大小写敏感，确保库名用反引号包裹，比如
`my-db`，否则语法报错 - 权限生效不依赖连接重连，但已有连接不会自动获得新权限，建议让应用重建连接或等连接池轮换
使用视图封装跨库查询时权限怎么设
有人想建个视图把跨库逻辑藏起来，比如 CREATE VIEW order_with_customer AS SELECT …… FROM orders.o JOIN customers.c，但这反而会让权限更难搞——视图创建者权限不影响调用者，调用者仍需自己拥有底层所有表的权限。
- 视图本身不“携带”权限，它只是查询模板；执行时仍以调用者身份校验
orders.*和customers.* - 若坚持用视图，可改用
SQL SECURITY DEFINER，但要求定义者账号（如admin）有完整权限，且该账号密码 / 权限管理必须极其严格 - 更安全的做法是：放弃视图，改由应用层分两次查询 + 内存关联，或用存储过程（同样要确保调用者有对应库权限）
MySQL 8.0+ 的角色（ROLE）能否简化多库授权
可以，但要注意角色本身不自动绑定权限到用户，且角色权限仍是库级粒度，不能跳过“分别授权”这一步。
流程是：先建角色 → 给角色授两个库的 SELECT → 再把角色赋给用户：
CREATE ROLE 'cross_db_reader'; GRANT SELECT ON `orders`.* TO 'cross_db_reader'; GRANT SELECT ON `customers`.* TO 'cross_db_reader'; GRANT 'cross_db_reader' TO 'app_user'@'%'; SET DEFAULT ROLE 'cross_db_reader' TO 'app_user'@'%';- 最后一步
SET DEFAULT ROLE很关键，否则用户登录后角色不激活，权限不生效 - 角色适合权限结构稳定的场景；如果某个库下周要下线，记得同步从角色里
REVOKE对应权限，否则容易遗留风险 - MySQL 5.7 不支持角色，别在旧版本上试这个流程
跨库权限真正的复杂点不在语法，而在于权限变更的可见性——开发测的时候用 root 没问题，一上预发就卡在 SELECT command denied，因为测试账号漏授了一个库。上线前务必用实际账号跑一遍完整 SQL，别只看 GRANT 语句有没有执行成功。
