MySQL跨库JOIN不支持索引下推优化，因InnoDB在单库内维护索引元数据，跨库即独立表空间，EXPLAIN中被驱动表key为NULL、type为ALL即证实只能走BNL；替代方案仅有三类：建临时表并索引、应用层双查合并、或数据同步至同库。
MySQL跨库JOIN根本不能用本地索引
MySQL不支持跨库（db1.table_a JOIN db2.table_b）的索引下推优化，这不是配置或写法问题，而是存储引擎层的硬限制：InnoDB只在单库（single database/schema）内维护索引元数据和B+树结构，跨库意味着两个独立的表空间（.ibd文件），优化器无法将连接条件映射到对方库的索引上。
EXPLAIN里key字段为空或显示NULL就是铁证
执行 EXPLAIN SELECT * FROM db1.orders o JOIN db2.users u ON o.user_id = u.id 后，观察 EXPLAIN 输出中 u 表那一行的 key 字段——它一定是 NULL 或空字符串，type 往往是 ALL，rows 是全表行数。这说明优化器已放弃对 db2.users 做任何索引查找，只能走 Block Nested Loop（BNL），把 db1.orders 的匹配结果缓存在 join_buffer 里，再逐行扫描 db2.users 全表比对。
替代方案只有三种，没有“加个索引就解决”这种选项
遇到必须跨库关联的场景，只能选以下路径之一：
- 把被驱动表（通常是小表）临时导出为本地临时表：
CREATE TEMPORARY TABLE tmp_users AS SELECT * FROM db2.users;，再对tmp_users建索引后 JOIN —— 但要注意事务隔离与数据一致性 - 改用应用层双查：先查
db1.orders，提取所有user_id，再用IN批量查db2.users，在代码里合并 —— 适合user_id数量可控（比如 - 物理合并库：把
db2.users以视图或同库表方式接入db1（如用 FEDERATED 引擎或 MySQL 8.0+ 的 Data Dictionary 抽象），但 FEDERATED 性能差、不稳定，且不支持事务，生产环境慎用
最容易被忽略的坑：字符集/排序规则不一致会雪上加霜
即使强行用 FEDERATED 或中间表绕过跨库限制，若 db1.orders.user_id 和 db2.users.id 的字符集（如 utf8mb4_general_ci vs utf8mb4_0900_as_cs）或长度（VARCHAR(32) vs VARCHAR(64)）不一致，仍会触发隐式转换，让本可生效的索引彻底失效。检查方法是看 SHOW CREATE TABLE 输出中的 COLLATE 和 CHARACTER SET 字段，必须完全一致。
