跨库查询失败主因是权限配置不到位，必须分别对每个库显式授予select权限，且用户、主机名、库名（含反引号）须完全匹配，否则join操作会报error 1142。
跨库查询本身没有问题，出错几乎全是权限配置不到位导致的——哪怕你对两个库都执行过 GRANT SELECT，只要其中任意一个漏掉、主机名不匹配、或者用了通配符却没加反引号，SELECT * FROM db1.t1 JOIN db2.t2 就会直接报 ERROR 1142 (42000): SELECT command denied。
为什么显式授予每个库的 SELECT 权限是必须的
MySQL 的权限检查不是“用户有没有跨库能力”，而是逐对象校验：执行 db1.t1 JOIN db2.t2 时，会分别检查调用者是否有 db1.t1 的 SELECT 权限，以及 db2.t2 的 SELECT 权限。这两个权限必须独立存在，不能靠“继承”或“通配”自动覆盖。
- 错误写法：
GRANT SELECT ON `db%`.* TO 'u'@'%'—— 通配符在GRANT中有效，但仅限于数据库名匹配，且必须用反引号包裹含特殊字符或大小写的库名（如`my-db`） - 正确做法：对每个目标库单独执行
GRANT SELECT ON `orders`.* TO 'app_user'@'%'和GRANT SELECT ON `customers`.* TO 'app_user'@'%' - 注意主机名差异：
'app_user'@'localhost'和'app_user'@'%'是两个完全独立的账号，权限不共享
跨库视图无法绕过权限检查
有人想建个视图封装 CREATE VIEW v AS SELECT ... FROM db1.t1 JOIN db2.t2，再只给用户查视图的权限——这行不通。视图执行时仍以调用者身份做权限校验，用户依然需要同时拥有 db1.* 和 db2.* 的 SELECT 权限。
- 改用
SQL SECURITY DEFINER可绕过调用者权限限制，但要求定义者（如DEFINER='admin'@'localhost'）本身有完整权限，且该账号必须严格管控（禁用弱口令、限定连接源、不暴露给应用） - 更稳妥的做法是放弃视图，由应用层分两次查询 + 内存关联，或改用存储过程（同样需确保调用者具备底层所有库的对应权限）
MySQL 8.0+ 角色（ROLE）能简化但不跳过授权步骤
角色可以批量管理权限，但不能省掉“分别授权”这个动作。它只是把重复操作收拢到角色上，再赋给用户。
- 流程必须是：先
CREATE ROLE 'cross_reader'；再GRANT SELECT ON `orders`.* TO 'cross_reader'和GRANT SELECT ON `customers`.* TO 'cross_reader'；最后GRANT 'cross_reader' TO 'app_user'@'%' - 角色本身不自动生效，用户需执行
SET ROLE 'cross_reader'（或设为默认角色），否则权限不会激活 -
FLUSH PRIVILEGES在用GRANT修改权限后通常不需要——除非你直接改了mysql.db表这类系统表
最容易被忽略的一点：已有数据库连接不会自动获得新权限，应用必须重建连接或等连接池自然轮换，否则即使 SHOW GRANTS 看起来已生效，查询仍会失败。
