索引合并是MySQL等数据库在多字段查询时协同使用多个单列索引的优化策略，适用于AND/OR独立条件且无合适联合索引的场景，包含union、intersect、sort_union三种方式，但性能通常不如覆盖联合索引。
当查询条件涉及多个字段时，数据库可以利用多个索引协同工作，而不是只能用一个。这种“索引合并”（Index Merge）是MySQL等数据库优化器支持的一种执行策略，能在没有合适联合索引的情况下，仍较高效地完成多条件查询。
什么情况下会触发索引合并
索引合并通常在以下场景被优化器选中：
- WHERE子句中包含多个独立的条件，且每个条件都可命中不同单列索引（如 WHERE a = 1 AND b = 2，a 和 b 各有单列索引）
- 条件之间是 OR 关系，且各分支能走不同索引（如 WHERE a = 1 OR b = 2）
- 没有覆盖全部查询字段的联合索引，但存在多个部分匹配的单列索引
三种常见索引合并方式
MySQL 支持三种索引合并算法，执行计划中会显示为 index_merge，并注明具体类型：
- union：对应 OR 条件，对多个索引分别扫描，再取并集（如 key: a,b）
- intersect：对应 AND 条件，对多个索引分别扫描，再取交集（如 key: a,b）
- sort_union：OR 条件中含范围查询（如 a = 1 OR b > 10），需排序合并结果
如何判断是否用了索引合并
通过 EXPLAIN 查看执行计划：
- type 列显示为 index_merge
- key 列列出多个索引名（如 key: idx_a,idx_b）
- Extra 列可能出现 Using union(idx_a,idx_b) 或类似提示
注意：PostgreSQL 和 SQL Server 默认不支持索引合并，主要依赖位图扫描或手动创建复合索引替代。
比索引合并更优的替代方案
索引合并虽有用，但通常比不上精心设计的联合索引高效：
- 合并过程需额外做集合运算（交/并），有CPU和临时结构开销
- 无法避免回表（除非所有索引都是覆盖索引）
- 优化器有时会误判，宁可用全表扫描也不选合并
建议优先考虑：为高频多条件查询建立合适的联合索引，例如 WHERE user_id = ? AND status = ? AND created_at > ?，可建 (user_id, status, created_at) 覆盖索引。
