MySQL 8.0 的跨库联合查询功能原生内置，无需额外安装插件或修改配置文件。很多开发者遇到 SQL 语法正确却报 ERROR 1142 的情况时，常会困惑——其实并非 MySQL 限制跨库操作，而是权限验证环节未通过。
简而言之，跨库查询受阻的根源通常不是功能未启用，而是权限分配不完整或授权语句编写不当。
最常见的场景：执行 SELECT FROM db1.t1 JOIN db2.t2 时返回 ERROR 1142。这不是语法错误，而是权限验证失败。MySQL 对每个数据库的 SELECT 权限独立检查——即使拥有 db1 的全部权限，若 db2 未授予 SELECT，JOIN 操作在访问第二张表时便会中断。
- 使用
SHOW GRANTS FOR CURRENT_USER;查看授权结果，输出中必须包含至少两行：GRANT SELECT ON `db1`.*和GRANT SELECT ON `db2`.*，缺一不可。 - 账号匹配问题需留意：若用户为
'app'@'10.20.30.40'，却仅授予了'app'@'%'，二者权限不互通，必须确保 Host 完全一致。 - 数据库名若包含特殊字符（如
my-app中的短横线），需使用反引号包裹。直接写GRANT SELECT ON my-app.*会引发ERROR 1144，正确形式为GRANT SELECT ON `my-app`.*。
那么，如何编写 GRANT 语句才能兼顾安全与效率？
切勿直接操作 mysql.db 表，也不应滥用 GRANT ALL ON *.*。生产环境中，最可靠的方式是逐库显式授权，每条命令独立执行。
- 对每个目标数据库分别执行
GRANT SELECT ON `db_name`.* TO 'user'@'host';。例如：GRANT SELECT ON `orders`.* TO 'reporter'@'%';。 - 授权完成后立即执行
FLUSH PRIVILEGES;，尤其在非 root 用户环境中，此步骤不可或缺，能确保权限立即生效。 - 一个易被忽视的细节：若应用连接池未重建，现有连接不会自动获取新权限。解决方案包括等待连接自然轮换或手动重启连接池。
跨库 JOIN 操作中，表名与别名的书写格式同样容易出错。
不要误以为执行 USE db1; 后即可省略库名前缀，MySQL 不会自动推断上下文。所有跨库引用必须显式完整写出，反引号的使用不可省略。
- 正确写法示例：
SELECT u.name, o.amount FROM `users_db`.`users` u JOIN `orders_db`.`orders` o ON u.id = o.user_id; - 典型错误：
SELECT * FROM users JOIN orders_db.orders，其中users缺少库前缀，MySQL 将在当前 USE 的数据库中查找，导致失败。 - 另一个常见误区：使用
`users_db.users`格式错误，反引号应分别包裹库名和表名，即`users_db`.`users`才是合法写法。 - 字符集不一致问题：若一个库使用
utf8mb4_0900_as_cs，另一个使用utf8mb4_general_ci，JOIN 时字段会发生隐式转换，可能导致索引失效。
最后强调两个极易被忽略的要点：第一，权限是否生效不取决于配置文件修改，而应验证 SHOW GRANTS 输出是否包含所有目标数据库。第二，跨库 SELECT 操作可以正常执行，但一旦涉及 UPDATE 或 INSERT，跨库事务将无法自动回滚——这一保证需由应用层自行实现。
