数据库查询优化中的索引合并（Index Merge）优化原理解析 题目描述 索引合并（Index Merge）是数据库查询优化器处理对同一表的多列条件查询时的一种技术。当WHERE子句中包含多个独立条件（通常用AND或OR连接），且每个条件可分别利用不同索引时，优化器可能选择同时扫描多个索引，再将结果合并（交集或并集），以避免全表扫描。例如，对 WHERE a = 1 AND b = 2 ，若列 a 和 b 均有独立索引但无联合索引，索引合并可通过分别索引扫描后取交集加速查询。 解题过程循序渐进讲解 问题场景分析 假设表 t 有列 a 、 b ，分别建有单列索引 idx_a 和 idx_b ，但未创建联合索引 (a, b) 。 查询语句： SELECT * FROM t WHERE a = 1 AND b = 2 。 若无索引合并，优化器可能面临两难选择： 使用 idx_a 找到所有 a=1 的行，再逐行检查 b=2 （需回表过滤）。 使用 idx_b 找到所有 b=2 的行，再逐行检查 a=1 （需回表过滤）。 若满足条件的行较少，单索引扫描+回表过滤尚可接受；但若两列条件筛选性均较弱，回表成本可能很高，甚至不如全表扫描。 索引合并的基本思想 核心思路： 同时利用多个索引 ，分别获取部分结果，再通过集合操作（交集、并集）合并中间结果，减少回表次数。 适用条件： 查询条件包含多个独立子条件（如 a=1 、 b=2 ）。 每个子条件可匹配一个索引（列顺序不限）。 合并操作的代价低于单索引扫描+回表过滤或全表扫描。 索引合并的三种类型 交集合并（Index Merge Intersection） ： 用于AND条件（如 a=1 AND b=2 ）。 步骤： 分别通过 idx_a 和 idx_b 扫描，得到满足 a=1 和 b=2 的 主键集合 。 对两个主键集合取交集（例如使用哈希或排序合并算法）。 根据交集的主键回表读取完整数据行。 优势：仅对交集主键回表，避免无效回表。例如若 a=1 有1000行， b=2 有1000行，交集仅10行，则回表次数从1000次降至10次。 并集合并（Index Merge Union） ： 用于OR条件（如 a=1 OR b=2 ）。 步骤： 分别通过 idx_a 和 idx_b 扫描，得到满足 a=1 和 b=2 的主键集合。 对两个主键集合取并集（去重）。 根据并集的主键回表读取数据。 优势：避免全表扫描，尤其当OR条件中每个子条件筛选性较强时。 排序并集合并（Sort-Union Merge） ： 用于OR条件，但索引返回的主键无序时（如范围查询 a < 10 OR b > 100 ）。 步骤： 分别扫描索引得到主键集合。 对每个主键集合单独排序。 合并有序主键列表（类似归并排序）。 与普通并集合并的区别：需排序保证合并效率，适用于非等值查询。 优化器选择索引合并的考量因素 索引筛选性 ：若某个索引的条件匹配行数过少，优化器可能直接选择该索引+回表过滤，而非合并。 回表成本 ：若主键较大或数据行分散，回表成本高，合并更有利。 合并操作成本 ：取交集/并集需内存或临时表存储中间结果，若主键数量大，可能反而比单索引扫描慢。 统计信息准确性 ：依赖表统计信息（如基数、数据分布）估算代价，统计信息过期可能导致优化器误判。 索引合并的局限性 不支持跨表合并 ：仅针对同一表的多个索引。 索引类型限制 ：通常要求索引为B+树，且合并的索引需覆盖查询条件的所有列。 OR条件的限制 ：并集合并要求每个OR子条件均能使用索引，否则可能退化为全表扫描。 性能波动风险 ：若交集/并集的结果集很大，合并操作可能成为瓶颈。 实践建议 优先考虑联合索引 ：对于高频的AND多列查询，创建联合索引 (a, b) 可直接通过索引定位，避免合并开销。 监控执行计划 ：通过 EXPLAIN 查看是否使用 Index Merge （如MySQL的 type 字段显示 index_merge ）。 谨慎使用OR查询 ：复杂的OR条件可能触发排序并集合并，需测试实际性能。 总结 索引合并通过“分治”策略将多条件查询分解为多个索引扫描，再合并结果，是优化器在缺乏理想联合索引时的补救措施。理解其原理有助于合理设计索引，并通过执行计划分析调优查询性能。