跨引擎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
