为何MySQL无法始终在此场景下使用Index Merge（索引合并）？

这种索引合并在不同数据集下“双标”的情况确实挺闹心的，尤其是业务要求返回大量数据行的时候——我来帮你拆解下问题，一步步找到解决方案：

先搞懂为什么ref=const会卡住Index Merge #

MySQL优化器遇到ref=const的常量等值匹配条件时，默认会优先选单索引查询，它觉得这种方式在多数小数据场景下效率更高。但当你的查询要返回大量数据时，单索引遍历的成本反而会超过多个索引合并后的扫描成本，可优化器没意识到这一点。

针对性调整方案 #

1. 先试试强制触发Index Merge（应急用） #

如果你确定Index Merge是更优选择，可以直接用优化器提示硬启用：

SELECT /*+ INDEX_MERGE(your_table idx_name1 idx_name2) */ *
FROM your_table
WHERE [你的业务查询条件];

注意把your_table和idx_name1/2换成你实际的表名和要合并的索引名。不过这只是临时方案，咱们还是要让优化器自主做出正确选择，所以继续看长期优化。

2. 调整优化器成本参数，引导它选Index Merge #

MySQL优化器靠成本计算选执行计划，大数据集下它可能误判单索引扫描成本更低，你可以微调这些参数：

• 增大read_rnd_cost：这个参数控制随机读取的成本，返回大量数据时，随机读取的开销会被放大，让优化器更倾向于选索引合并的顺序扫描。
• 确保optimizer_switch里的索引合并开关都打开。

执行下面的命令临时调整（要持久化的话记得改my.cnf）：

SET SESSION read_rnd_cost = 4; -- 默认是2，适当增大即可
SET SESSION optimizer_switch = 'index_merge=on,index_merge_union=on,index_merge_intersection=on';

3. 检查查询条件和索引设计 #

• 确保查询条件里的字段都有独立的单列索引，Index Merge主要依赖多个单列索引的组合；
• 别用函数包裹索引字段，比如DATE(create_time) = '2024-01-01'会直接让索引失效，更别提触发合并了；
• 如果优化器认为全表扫描比索引合并更高效，你可以实际对比两种方式的执行时间，再决定要不要强制引导。

4. 更新表统计信息，让优化器“看清”数据 #

存储过程生成的大数据集可能有特殊的数据分布（比如某个字段重复值极多），优化器靠旧的统计信息会误判。执行ANALYZE TABLE your_table;更新统计数据，让它能准确计算成本。

验证调整效果 #

每次调整后用EXPLAIN看执行计划，确认是否出现type: index_merge，以及Extra字段里有没有Using index merge(union/intersection)的提示。同时一定要对比实际执行时间，确保调整后真的提升了性能。

小提醒：Index Merge不是银弹，有些场景下，专门创建一个覆盖所有查询条件的联合索引，可能比依赖优化器的索引合并更稳定哦。

内容的提问来源于stack exchange，提问作者Lightness Races in Orbit