数据库的查询执行计划中的索引合并优化技术

描述
索引合并（Index Merge）是数据库查询优化器在处理复杂查询条件时的一种技术。当查询包含多个基于不同索引的过滤条件（如多个AND/OR条件）时，优化器可能选择同时使用多个索引，分别检索数据后再合并结果，以替代全表扫描或单一索引扫描。这种技术尤其适用于单列索引较多但缺乏合适复合索引的场景。

解题过程

1. 索引合并的适用场景

• 条件类型：
  • WHERE子句中包含多个条件，且每个条件可匹配不同索引（例如col1 = 1 AND col2 = 'abc'，col1和col2均有单列索引）。
  • 条件间关系可为AND（交集合并）或OR（并集合并）。
• 优势：避免全表扫描，减少不必要的复合索引数量。
• 局限性：合并操作本身需要额外开销（如排序、去重），可能不如高效的复合索引。

2. 索引合并的常见类型

• 交集合并（Index Merge Intersection）：

  • 适用于AND条件。
  • 分别从多个索引中获取满足条件的行ID（或主键），取交集后回表查询数据。
  • 示例：

    SELECT * FROM table WHERE index_col1 = 1 AND index_col2 = 2;  
    

    • 步骤：
      1. 通过索引A找到index_col1 = 1的所有行ID。
      2. 通过索引B找到index_col2 = 2的所有行ID。
      3. 对两组行ID取交集。
      4. 根据交集结果回表获取完整数据行。

• 并集合并（Index Merge Union）：

  • 适用于OR条件或不同索引的覆盖查询。
  • 合并多个索引的结果集并去重。
  • 示例：

    SELECT * FROM table WHERE index_col1 = 1 OR index_col2 = 2;  
    

    • 步骤：
      1. 分别从索引A和索引B获取满足条件的行ID。
      2. 合并两组行ID并去重（避免重复访问同一行）。
      3. 回表获取数据。

• 排序并集合并（Sort-Union）：

  • 当索引返回的行ID无序时，先排序再合并（用于解决并集合并的乱序问题）。

3. 索引合并的执行流程
以交集合并为例的详细步骤：

1. 索引扫描阶段：

   • 对每个可用的索引执行范围扫描或等值查询，获取行ID（或主键）集合。
   • 例如，MySQL使用index_col1索引找到行ID集合S1，使用index_col2索引找到S2。

2. 行ID合并阶段：

   • 对多个行ID集合进行交集/并集操作。
   • 交集合并通常采用有序列表的合并算法（要求行ID有序），避免排序开销。

3. 回表查询阶段：

   • 根据合并后的行ID访问主索引（聚簇索引）获取完整数据行。
   • 若索引本身覆盖查询列（即索引包含所有SELECT字段），可跳过回表。

4. 优化器选择索引合并的考量因素

• 索引选择性：若某个条件过滤性差（如返回大量行），优化器可能倾向全表扫描。
• 合并成本：合并操作需要CPU和内存资源，若行ID集合过大，可能放弃合并。
• 索引覆盖度：若合并后仍需大量回表，可能不如直接使用复合索引。

5. 实际案例与调优建议

• 案例：

  -- 表结构：id (主键), name索引, age索引  
  SELECT id, name FROM users WHERE name = 'Alice' AND age = 30;  
  

  • 若name和age索引的选择性均较高，优化器可能选择索引合并：
    1. 通过name索引找到所有name='Alice'的行ID。
    2. 通过age索引找到所有age=30的行ID。
    3. 取交集后回表查询id和name。

• 调优建议：

  • 优先使用复合索引：若查询条件固定，创建(name, age)复合索引可避免合并开销。
  • 监控合并效果：通过执行计划（如MySQL的EXPLAIN）观察type=index_merge是否高效。
  • 避免过度索引：单列索引过多可能误导优化器选择次优的合并计划。

总结
索引合并是优化器在缺乏理想复合索引时的补救策略，通过组合多个单列索引的结果平衡查询效率。理解其原理有助于设计更合理的索引策略，并通过执行计划分析优化实际查询性能。