应先验证当前用户可见的库和表：运行SHOW DATABASES确认目标库是否存在，再用SHOW TABLES FROM db_name检查表权限，最后通过information_schema.tables验证元数据访问权。
直接查当前用户能访问哪些库和表
权限不足时，SELECT 语句在跨库 JOIN 中会报 ERROR 1142 (42000): SELECT command denied to user，但错误里不显示库名，只写 table 'orders'——这容易让人误以为是表不存在。最稳的前置动作是先确认当前用户实际能看到什么：
- 运行
SHOW DATABASES;—— 如果目标库没列出来，说明连库级SELECT权限都没有 - 对每个涉及的库，执行
SHOW TABLES FROM order_db;—— 看是否能列出表名；如果报错或返回空，权限已卡住 - 用
SELECT * FROM information_schema.tables WHERE table_schema = 'order_db' AND table_name = 'orders';验证能否读取元数据（需information_schema访问权）
检查具体表的SELECT权限是否生效
MySQL 权限校验按层级降序检查：先看 mysql.user 的全局权限，再查 mysql.db 的库级权限，最后落到 mysql.tables_priv。单靠 SHOW GRANTS FOR CURRENT_USER; 不够，因为：
- 它只显示显式授予的权限，不反映
mysql.db表中通过GRANT SELECT ON order_db.*这类库级授权 - 如果用户是
'user'@'192.168.%'，而连接时用的是'user'@'192.168.1.100'，权限匹配成功；但若连的是'user'@'localhost'，可能命中另一条更精确的Host记录，权限反而不同 - 务必对比
USER()和CURRENT_USER()：前者是你登录时写的账号，后者才是 MySQL 实际匹配到的权限主体
用最小化SQL验证跨库JOIN可行性
别一上来就跑完整业务查询。先构造一个极简、无业务逻辑、只测通路的语句：
SELECT 1 FROM user_db.users u JOIN order_db.orders o ON u.id = o.user_id LIMIT 1;
这个语句只检查三件事：能否访问两个库、能否读两个表、能否做 JOIN（不依赖索引或数据量）。如果它失败，问题一定出在权限或库/表存在性上；如果它成功，再逐步加字段、加条件、加 WHERE 或 GROUP BY 排查其他瓶颈。
- 注意：即使
users和orders都有索引，如果o.user_id没索引，这个语句仍可能慢，但不会因权限报错 - 如果用到了视图或存储过程，还要额外确认
SQL SECURITY设置——DEFINER模式下，权限检查对象是创建者，不是调用者
权限变更后必须刷新，且连接复用会影响验证结果
授完权别忘了 FLUSH PRIVILEGES;，但这只是让 MySQL 重新加载权限表。更重要的是：
- 已存在的连接不会自动更新权限，必须断开重连才能生效
- 应用层如果用了连接池（如 HikariCP、Druid），旧连接可能缓存数分钟，导致“明明刚授了权，查询还是报错”
- 临时解决方案：在应用配置里设
connectionInitSql=SELECT 1，或手动 kill 对应连接：KILL CONNECTION_ID;
跨库 JOIN 的权限边界很硬，没有绕过方式。哪怕两个库物理上完全共存，只要权限没开到对应库表，就卡死在 ERROR 1142。最容易被忽略的是：错误信息里从不提库名，排查时得主动去查 CURRENT_USER() 和 SHOW GRANTS，而不是盯着报错里的表名打转。
