index merge不能被强制使用，仅当优化器估算成本后认为其最优或别无选择时才启用；use index/ignore index等提示因语义冲突无法触发，真正影响决策的是索引结构、数据分布及optimizer_switch开关设置。
不能“强制”使用 Index Merge，只能通过关闭更优路径、制造优化器“别无选择”的条件来间接诱导它走这条路。 MySQL 优化器不会因为你加了 USE INDEX 或写得再漂亮就启用 Index Merge；它只在估算成本后认为这是当前最优（或次优但可接受）方案时才用。盲目追求 Index Merge，往往说明联合索引没建好。
为什么 USE INDEX 不会触发 Index Merge
因为 USE INDEX 的语义是“只允许用这几个索引中的某一个”，而 Index Merge 的前提是“必须同时用多个索引”。两者逻辑冲突——USE INDEX (idx_a, idx_b) 实际上等价于“从 idx_a 和 idx_b 里选一个”，不是“一起用”。优化器看到这个 hint，会直接排除 Index Merge 路径。
- 想验证是否走了 Index Merge，唯一可靠方式是看
EXPLAIN的type字段是否为index_merge，以及Extra是否含Using intersect()等字样 -
FORCE INDEX同样无效，它只是把某个索引设为“必须用”，不改变“单索引”前提 - 真正能影响 Index Merge 决策的是
optimizer_switch开关和索引结构本身
如何让优化器“倾向于”选择 Index Merge
本质是移除它更喜欢的替代方案，尤其是覆盖型联合索引。当优化器发现走单个索引代价太高（比如范围扫描返回太多行、回表开销大），又没有更好的联合索引可用时，Index Merge 才可能被选中。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 删掉已存在的联合索引，例如已有
INDEX(a, b)，就删掉它——否则优化器几乎一定选它，而不是INDEX(a)+INDEX(b) - 确保各单列索引是“完整前缀等值匹配”：WHERE 中必须是
a = ? AND b = ?，不能是a > ? AND b = ?（后者大概率触发index_merge_sort_union，性能更差） - 避免前缀索引干扰：如
INDEX(name(10))在name = 'abc'查询中可能被忽略，导致优化器无法将其纳入 Intersection 计算 - 临时关闭更优路径：执行
SET SESSION optimizer_switch='index_merge=on,index_merge_intersection=on,use_index_extensions=off';，同时用IGNORE INDEX把联合索引屏蔽掉
UPDATE/DELETE 场景下 Index Merge 的危险信号
在写操作中诱导 Index Merge 是高风险行为，尤其当 WHERE 条件含 AND 且依赖两个单列索引时，InnoDB 加锁顺序不确定，极易引发死锁。
- 例如
UPDATE t SET x = 1 WHERE a = 10 AND b = 20，若只有INDEX(a)和INDEX(b)，优化器可能走index_merge_intersection，但两个索引扫描的主键顺序不同，事务并发时容易形成循环等待 - 死锁日志里若出现类似
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: index idx_a of table `db`.`t`和*** (2) HOLDS THE LOCK(S): index idx_b of table `db`.`t`，基本可断定是 Index Merge 导致 - 此时正确做法不是“强制它用”，而是补上
INDEX(a, b)，让优化器自然走range或ref，锁范围可控、顺序确定
真正需要关注的不是“怎么强制”，而是“为什么优化器觉得 Index Merge 是次优解”——那通常意味着索引设计存在缺口，或者数据分布让单索引失效。修复根因比绕过机制更可靠。
