跨引擎JOIN时索引大概率失效，因存储引擎底层机制不支持索引下推；MyISAM与InnoDB混用还存在锁冲突、一致性风险及WHERE条件性能断崖。

JOIN跨引擎表时索引会失效吗

会，而且大概率完全不走索引——不是MySQL“没优化好”，是存储引擎底层机制根本不支持跨引擎索引下推。InnoDB的B+树索引、MyISAM的BTREE、Memory的HASH，各自维护方式、锁粒度、事务语义都不同，优化器在生成执行计划时，对非主表（尤其是被驱动表）几乎无法复用其索引结构。

实操建议：

• 用 EXPLAIN 查看 type 字段：如果出现 ALL 或 index（而非 ref/eq_ref），基本说明被驱动表没走有效索引
• 强制指定驱动表：用 STRAIGHT_JOIN 把高选择性、有好索引的表放在 FROM 侧，避免优化器误选MyISAM表当驱动表
• 别依赖 USE INDEX：对跨引擎JOIN，该提示常被忽略，因为索引访问路径根本不可跨引擎复用

MyISAM和InnoDB混用JOIN的锁与一致性风险

MyISAM只支持表级锁，InnoDB是行级锁 + MVCC，JOIN过程中二者锁行为完全不兼容。最典型的问题是：一个事务中更新InnoDB表后JOIN MyISAM表，MyISAM部分可能读到旧快照，也可能被其他线程的写操作阻塞，结果既不一致也不可预测。

常见错误现象：

• 查询偶尔卡住几秒，SHOW PROCESSLIST 显示 Locked 状态
• 同一SQL在不同时间返回不同结果，且无显式事务控制
• SELECT ... JOIN 被另一个线程的 ALTER TABLE（MyISAM）阻塞

使用场景上，除非是只读报表且能接受分钟级延迟，否则应避免混合。若必须用，把MyISAM表全量导入临时InnoDB表再JOIN更可靠。

WHERE条件里字段来自不同引擎时的性能断崖

当 WHERE 中的过滤条件涉及两个引擎的字段（比如 t1.id = t2.id AND t2.status = 'done'），优化器往往放弃使用任一表的索引，转为嵌套循环+全表扫描。因为无法将谓词下推到MyISAM层做早期过滤，InnoDB侧的索引也因关联键分布不可知而难以估算成本。

参数差异影响明显：

• join_buffer_size 对跨引擎JOIN效果极差——它只加速无索引JOIN，但MyISAM表本身不参与索引匹配逻辑
• optimizer_switch='block_nested_loop' 开启反而更慢，因为BLN无法利用MyISAM的键顺序
• 改用子查询重写（如 IN (SELECT ... FROM MyISAM)）有时比直接JOIN快，因MySQL会对子查询做物化缓存

替代方案：什么时候该用FEDERATED或外部ETL

FEDERATED引擎表面看能“统一访问”，实际只是把查询转发给远程MySQL，本地仍无索引协同能力，网络延迟+单点故障让它在生产JOIN场景中基本不可用。真正可行的路只有两条：

• 定期同步：用 mysqldump --no-create-info 或 SELECT ... INTO OUTFILE 导出MyISAM数据，再用 LOAD DATA INFILE 导入InnoDB临时表，确保JOIN全程在单一引擎内完成
• 应用层分步查：先查InnoDB主表获取ID列表，再用 WHERE id IN (...) 查MyISAM表——虽然多一次网络往返，但可控、可缓存、可加超时

复杂点在于MyISAM表如果有TEXT/BLOB字段，导出导入过程容易截断；更隐蔽的是时区和SQL_MODE差异，比如MyISAM建表时用 DEFAULT CURRENT_TIMESTAMP，导入InnoDB后可能变成0000-00-00