跨库JOIN报ERROR 1142主因是CURRENT_USER()对应账号权限不足，须用SHOW GRANTS FOR CURRENT_USER()确认是否已显式授予目标库SELECT权限，且授权必须匹配实际认证账号（如'app_user'@'%'而非'app_user'@'192.168.1.100'），权限生效需FLUSH PRIVILEGES并重启连接池。
先确认 CURRENT_USER() 是谁，不是你以为的登录账号
执行 SELECT USER(), CURRENT_USER(); —— 90% 的跨库 JOIN 权限报错，根源是 MySQL 实际认证的账号和你输入的不一致。比如你用 app_user@192.168.1.100 登录，但匹配到的是 app_user@% 或 app_user@localhost，而后者可能根本没授过 order_db 的权限。
重点看 CURRENT_USER() 返回值，后续所有授权、查权限、排错都必须基于它，不是 USER()。
用 SHOW GRANTS FOR CURRENT_USER() 验证真实权限
SHOW GRANTS FOR CURRENT_USER(); 是唯一反映当前会话实际生效权限的命令。别写成 SHOW GRANTS FOR 'app_user'@'192.168.1.100'，那条记录可能压根不存在，或权限未激活。
- 如果输出只有
GRANT USAGE ON *.* TO ...，说明该账号只允许登录，连SHOW DATABASES都会失败 - 如果没看到类似
GRANT SELECT ON `order_db`.* TO ...或GRANT SELECT ON `order_db`.`orders` TO ...，就说明缺跨库权限 - MySQL 8.0+ 支持
SHOW GRANTS FOR CURRENT_USER() ON order_db.orders;，可精准验证单表权限；旧版本跳过即可
跨库 JOIN 报 ERROR 1142 时，错误信息不显示库名
报错像 ERROR 1142 (42000): SELECT command denied to user 'u'@'%' for table 'orders'，这里的 table 'orders' 实际指 order_db.orders，但错误里故意省略库名——这是 MySQL 的设计，不是 bug。
别猜，直接验证：
- 运行
SHOW DATABASES;看order_db是否在列表中 - 执行
SHOW TABLES FROM order_db;，如果报错或返回空，说明连库级 SELECT 权限都没有 - 再试
SELECT 1 FROM order_db.orders LIMIT 1;，单独查被 JOIN 的表，排除 JOIN 逻辑干扰
权限补全后仍报错？检查连接复用与 FLUSH PRIVILEGES 时机
授完权立刻执行 GRANT SELECT ON order_db.* TO 'app_user'@'%'; 后，必须跟 FLUSH PRIVILEGES;。但这只是让 MySQL 重载权限表，不影响已建立的连接。
如果应用用了连接池（如 HikariCP、Druid），旧连接仍带着旧权限缓存，必须重启连接池或等连接自动回收。临时验证可用新终端重连测试。
另外注意：同一用户名不同 Host 是独立账号，'app_user'@'localhost' 和 'app_user'@'%' 的权限互不影响。别在本地连着 localhost 测试，却给 % 授权。
