MySQL optimizer hint 怎样临时禁止索引合并

如果只是想让一条查询暂时不要走 Index Merge，不必先改全局配置。更窄的做法是在查询块里写 NO_INDEX_MERGE optimizer hint，再用 EXPLAIN 对比提示前后的访问路径。没有索引参数时，它会禁止该表的 Index Merge；指定索引名时，只禁止涉及这些索引的合并组合。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/optimizer-hints.html

这类 hint 适合验证“是不是 Index Merge 让这条语句变慢”的假设，不等于永久修复。先留住原始执行计划，再做对照，最后决定是否应该调整索引、SQL 或系统级开关。

先判断应该控制整库还是单条语句

MySQL 的 optimizer_switch 是系统变量，适合控制某类优化策略的默认行为；NO_INDEX_MERGE 是语句级提示，适合把实验范围限制在一条查询上。两者不要混成同一种配置：

我的经验是，先用语句级 hint 做对照最容易回滚。只有多条业务 SQL 都需要相同策略，并且已经评估过副作用，才考虑会话或系统级配置。

用 NO_INDEX_MERGE 关闭指定表的索引合并

下面的例子把提示放在 SELECT 后面，并使用表别名 o。提示中的表名必须和查询里的别名对应：

-- 只禁止本条查询中 orders 表的 Index Merge
SELECT /*+ NO_INDEX_MERGE(o) */
       o.id, o.user_id, o.created_at
FROM orders AS o
WHERE o.user_id = 42
  AND o.status = 'paid';

如果只想排除涉及某几个索引的合并，可以把索引名写进提示：

-- 只禁止 idx_user_id 与 idx_status 参与 Index Merge
SELECT /*+ NO_INDEX_MERGE(o idx_user_id, idx_status) */
       o.id, o.user_id, o.status
FROM orders AS o
WHERE o.user_id = 42
  AND o.status = 'paid';

无索引参数的写法更直接，表示该表不允许 Index Merge；带索引参数的写法更窄，适合只验证某组索引组合。索引名不是列名，实际名称应以 SHOW INDEX FROM orders 或 INFORMATION_SCHEMA.STATISTICS 中的结果为准。

用 EXPLAIN 对照提示前后的访问路径

SQL 能正常返回，不代表 hint 已经带来预期变化。建议先记录不带 hint 的计划，再只增加 NO_INDEX_MERGE 做第二次对照：

-- 先观察原始计划，再与下一条带 hint 的计划比较
EXPLAIN
SELECT o.id, o.user_id, o.created_at
FROM orders AS o
WHERE o.user_id = 42
  AND o.status = 'paid';

-- 只改变优化器提示，其他查询条件保持一致
EXPLAIN
SELECT /*+ NO_INDEX_MERGE(o) */
       o.id, o.user_id, o.created_at
FROM orders AS o
WHERE o.user_id = 42
  AND o.status = 'paid';

对照时重点看 type、possible_keys、key、rows 和 Extra。原计划如果出现 index_merge，加提示后通常要观察它是否改成某个单独索引访问、范围访问或其他路径；不要只凭 key 变了就断言更快，仍要结合真实数据分布和耗时。

EXPLAIN ANALYZE 可以进一步提供实际执行信息，但它会真正执行语句，生产环境先确认查询是否允许这样做，并控制条件范围。

处理提示不生效和冲突情况

遇到“写了 hint 但计划没变”，按下面顺序排查：

1. 表别名不匹配：查询使用了 orders AS o 时，提示应引用 o，不要写成另一个别名。
2. 索引名写错：提示使用真实索引名，不要把 user_id 这类列名当成索引名。
3. 查询块位置不对：复杂 SQL 有子查询或多层查询块，提示要放在它所控制的查询块中；必要时使用查询块名限定作用域。
4. 组合本身不适用：官方文档允许优化器忽略不适用于当前语句的提示，因此不能把“语句成功”当成“提示一定生效”。
5. 多个控制项互相影响：同时写了相反的 Index Merge hint，或用 optimizer_switch 做了额外控制时，应保留最小复现 SQL，逐项删除并重新对照。

这里的目标是确认访问路径，不是强行让计划变成某一种样子。如果关闭 Index Merge 后变成全表扫描，说明这个 hint 可能只是帮助定位问题，并不适合直接上线。

形成可回滚的使用决策

可以把结论分成三类：

最后保留三份材料：原始 SQL、带 hint 的 SQL、两份 EXPLAIN 结果。这样后续索引或数据变化时，能够重新判断这个局部约束是否还值得保留。

常见问题

NO_INDEX_MERGE 是不是会删除索引？

不会。它只影响当前查询块对 Index Merge 访问方法的选择，不会修改表结构。

应该写 NO_INDEX_MERGE(o) 还是 NO_INDEX_MERGE(o idx_a)？

前者禁止该表的 Index Merge；后者只限制涉及指定索引的合并组合。排查阶段通常先用前者，再按需要收窄。

关闭 Index Merge 后一定更快吗？

不一定。它只是改变候选访问方法，最终效果取决于数据分布、过滤条件、统计信息和回表成本，必须用计划和实际耗时共同判断。