大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
某电商订单系统，开发人员给status和create_time分别建了单列索引。查询条件很简单：
SELECT * FROM orders
WHERE status = 'PAID' AND create_time > '2026-09-01'
ORDER BY create_time DESC LIMIT 20;
EXPLAIN一看，possible_keys列显示两个索引，优化器选择了索引合并（Index Merge） ，Extra列出现Using intersect(idx_status, idx_create_time)。
开发人员很高兴：“两个索引都用上了，优化器真智能！”
但实际跑起来，这条SQL在2000万数据的表上要3.8秒。加了个FORCE INDEX(idx_create_time)强制走单个索引，反而降到了0.3秒。
优化器“智能”地做了错误的决定。
今天把索引合并这件事彻底拆开，讲清楚它是什么、什么时候该用、什么时候千万别用。
一、索引合并的三种类型
MySQL的索引合并优化（Index Merge Optimization）在5.0时代就引入了，官方文档把它描述为一种“优化策略”，但不是“最优策略”。
1. Intersection（交集合并）
同时使用多个索引，取结果集的交集。
SELECT * FROM orders
WHERE user_id = 12345 AND status = 'PAID';
如果user_id和status各自有单列索引，优化器可能同时扫描两个索引，然后取交集。
2. Union（并集合并）
同时使用多个索引，取结果集的并集。
SELECT * FROM orders
WHERE user_id = 12345 OR status = 'PAID';
这是最危险的一种——两个索引的结果集取并集，需要去重、排序，代价极高。
3. Sort-Union（排序并集合并）
先对索引扫描结果排序，再去重合并。比普通Union多了排序步骤，代价更高。
一个设计良好的复合索引通常比索引合并更高效，因为单次索引查找就能定位数据，避免了合并开销。
二、索引合并的代价到底在哪？
索引合并看起来“利用了多个索引”，但代价隐藏在三个地方：
代价1：多次索引扫描 + 结果集合并
索引合并需要扫描多个索引树，然后把结果集在内存中做交集或并集运算。如果每个索引扫描返回的数据量都很大，合并操作本身的开销可能超过全表扫描。
代价2：随机I/O放大
索引扫描返回的是主键值（二级索引），然后需要回表读取完整行数据。索引合并意味着多次回表——每次索引扫描都要回表一次，I/O次数成倍增加。
代价3：基数估算偏差
优化器决定是否使用索引合并，依赖于基数估算（Cardinality Estimation）。如果统计信息过期或数据分布倾斜，优化器可能错误地认为索引合并很快，但实际上慢得要命。
三、3个真实踩坑场景
坑1：OR条件导致索引合并UNION，代价远超预期
SELECT * FROM orders
WHERE user_id = 12345 OR create_time > '2026-01-01';
优化器可能选择索引合并UNION——分别扫描idx_user_id和idx_create_time，然后合并去重。
但如果user_id=12345有10万行，create_time > '2026-01-01'有50万行，合并去重要处理60万行数据——比全表扫描还慢。
坑2：索引合并的基数估算偏差
MySQL优化器基于统计信息做决策。当统计信息过期时，优化器可能低估某个索引返回的行数，从而错误地选择索引合并方案。
坑3：多个单列索引 vs 一个复合索引
很多人有个误区：给每个查询条件列都建一个单列索引，让优化器自己去“合并”。
但复合索引通常比索引合并更高效——索引合并需要扫描多个索引、合并结果集、去重、排序；复合索引一次扫描就能定位到目标行。
-- 不推荐：两个单列索引让优化器去合并
CREATE INDEX idx_user_id ON orders(user_id);
CREATE INDEX idx_status ON orders(status);
-- 推荐：一个复合索引覆盖查询
CREATE INDEX idx_user_status ON orders(user_id, status);
四、什么时候该用索引合并，什么时候该用复合索引？
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 查询条件是AND，各条件选择性都很高 | 复合索引 | 一次索引查找定位，无合并开销 |
| 查询条件是AND，但其中一个条件选择性极低 | 单列索引+过滤 | 复合索引收益有限，索引合并代价高 |
| 查询条件是OR，各条件选择性都很高 | 索引合并UNION可接受 | 无法用单个复合索引覆盖OR条件 |
| 查询条件是OR，但结果集很大 | 改写SQL或用UNION ALL | 避免索引合并的去重和排序开销 |
| 查询条件经常变化，无法预建复合索引 | 索引合并作为兜底 | 聊胜于无，但需监控性能 |
五、怎么判断优化器是否选错了？
方法一：对比执行计划
分别用FORCE INDEX强制走单个索引和让优化器自由选择，对比响应时间。
方法二：查看EXPLAIN的Extra列
Using intersect(...)→ 交集合并，通常AND条件触发Using union(...)→ 并集合并，通常OR条件触发Using sort_union(...)→ 排序并集合并，代价最高
方法三：用EXPLAIN ANALYZE看实际行数
EXPLAIN ANALYZE会输出每个步骤的实际执行行数。如果actual rows远大于优化器估算的rows，说明基数估算有偏差。
方法四：使用OPTIMIZER_TRACE
开启optimizer_trace，可以看到优化器在索引合并和其他方案之间的代价对比，精确了解优化器为什么选了索引合并。
六、小结
索引合并是优化器的“兜底方案”，不是“首选方案”。能用复合索引解决的，优先用复合索引。如果EXPLAIN里出现了Using intersect或Using union，先确认索引合并的真实代价——很多时候，一个设计良好的复合索引比索引合并快一个数量级。索引合并的出现往往暗示你的索引设计还有优化空间。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
