MySQL 合并索引（Index Merge）

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

核心结论：Index Merge 是 MySQL 优化器在单表查询中，同时使用多个二级索引扫描并合并结果的访问方法，用于替代全表扫描，提升多条件查询效率。它仅作用于单表，基于二级索引（非聚簇索引），最终通过主键回表获取数据。

一、三种核心算法与适用场景

MySQL 支持 3 种合并策略，由优化器根据条件自动选择，可通过 EXPLAIN 精准识别。

典型示例

1. 交集（AND 等值）：SELECT * FROM user WHERE age=20 AND status=1（age、status 各有单列索引）
2. 并集（OR 等值）：SELECT * FROM user WHERE age=20 OR status=1
3. 排序并集（OR 范围）：SELECT * FROM user WHERE age>20 OR status=1

二、执行计划识别（EXPLAIN 关键字段）

通过 EXPLAIN 可快速判断是否使用 Index Merge，核心字段如下：

• type：显示为 index_merge（表示采用索引合并）
• key：列出所有使用的索引名称（如 idx_age,idx_status）
• Extra：显示具体算法（Using intersect(...)/Using union(...)/Using sort_union(...)）
• 扩展：用 EXPLAIN FORMAT=JSON 可查看更详细的合并逻辑与成本估算

三、关键限制与注意事项

1. 仅单表有效：不支持跨表索引合并，多表关联需依赖联表索引或关联条件
2. 不支持全文索引：全文索引无法参与 Index Merge 合并
3. 统计信息依赖：若统计信息过期，优化器可能误判，优先使用 ANALYZE TABLE 刷新
4. 无联合索引时的应急方案：Index Merge 是临时优化手段，无法替代联合索引的长期价值

四、优化策略（Java 后端实战）

1. 优先选择：联合索引（Composite Index）

对于高频多条件查询，联合索引的效率远高于 Index Merge（避免合并开销）。

• 示例：高频查询 age=20 AND status=1，直接创建联合索引 idx_age_status (age, status)，无需依赖 Index Merge
• 设计原则：高选择性字段在前，遵循最左匹配原则

2. 应急优化：利用现有单列索引

当无法修改表结构（如历史表）时，Index Merge 可快速提升查询效率，需注意：

• 避免选择性极差的索引参与（如 gender 仅男/女，扫描出大量主键，合并成本极高）
• 控制参与合并的索引数量，过多索引会显著增加合并开销

3. 覆盖索引优化

若查询仅需索引列，可创建覆盖索引，直接从索引获取数据，避免回表，提升 Index Merge 效率。

• 示例：SELECT age, status FROM user WHERE age=20 OR status=1，创建联合索引 idx_age_status (age, status) 作为覆盖索引

4. 临时禁用与调试

可通过 SQL 提示临时禁用 Index Merge，用于性能对比测试：

SELECT /*+ NO_INDEX_MERGE(user) */ * FROM user WHERE age>20 OR status=1;

五、配置与开关控制

Index Merge 相关功能由 optimizer_switch 系统变量控制，默认全部开启。可临时关闭测试：

-- 关闭所有 Index Merge 策略
SET optimizer_switch = 'index_merge=off';

-- 单独关闭 Sort-Union（针对范围 OR 场景）
SET optimizer_switch = 'index_merge_sort_union=off';

六、总结

Index Merge 是 MySQL 单表多条件查询的应急优化方案，核心价值是利用现有单列索引，避免全表扫描。但从长期维护与性能最优角度，优先设计合理的联合索引，平衡查询效率与索引维护成本。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花