当一条查询语句涉及多个过滤条件，而每个条件恰好命中不同索引时，数据库优化器面临一个关键抉择：是走单条索引然后过滤，还是同时走多条索引再合并结果？这个抉择在执行计划中以Index Merge的形式呈现，它看起来像是一种聪明的折中方案，但在大量生产场景中，Index Merge的实际表现往往令人大失所望。要真正理解这个问题，必须从执行计划的生成机制、各种索引访问路径的成本模型，以及数据分布对查询性能的深层影响这三个维度逐一剖析。

执行计划的本质是优化器对所有可能访问路径进行成本估算后的最优选择。对于一条带有多个等值或范围条件的查询，优化器通常会考虑以下几种路径：第一种是使用覆盖所有条件的复合索引，这是最理想的情况，扫描一次即可完成所有过滤；第二种是使用其中一个条件命中的单列索引，然后对返回的行用剩余条件进行过滤，这是最常见的单索引加后过滤方案；第三种就是Index Merge，即分别用多个单列索引扫描，再将结果集合并。优化器在做选择时，会基于统计信息估算每种路径的I/O成本、CPU成本和内存成本，最终选择总成本最低的方案。问题在于，这个成本估算模型在很多场景下并不准确，尤其是在回表代价和合并代价被低估时，优化器就会错误地选择Index Merge。

先来看Index Merge的三种合并方式。第一种是Union合并，适用于多个条件之间是或关系的查询，比如查询中包含或逻辑的多个等值条件。这种方式下，优化器分别走每个索引，将结果集取并集后去重。第二种是Intersect合并，适用于多个条件之间是与关系的查询，分别走每个索引后取交集。第三种是Sort-Union合并，与Union类似但不要求去重，适用于结果集本身不存在重复的场景。在这三种方式中，Union和Intersect的性能表现差异巨大，而这恰恰是很多开发者容易忽略的地方。

Index Merge的核心性能瓶颈首先来自回表。当查询需要返回的列不被索引覆盖时，每次通过索引定位到一条记录后，都需要回到主键索引或聚簇索引中取出完整的行数据，这个过程被称为回表。如果走单条索引，回表次数等于该索引扫描出的行数；但如果走Index Merge，回表次数等于所有索引扫描结果合并后的行数。在某些数据分布下，多条索引扫描出的中间结果集可能非常大，合并后虽然经过过滤，但回表的总量反而超过了走单索引加过滤的方案。更糟糕的是，如果多条索引扫描出的结果集有大量重叠，去重操作还会消耗额外的内存和CPU。一个典型的场景是，一张用户表上有性别和城市两个索引，查询条件是性别等于某值且城市等于某值。如果性别为男的用户占总用户的百分之六十，城市为某特定城市的用户占百分之三十，那么分别走这两个索引扫描出的行数可能高达数十万，而实际满足两个条件的行可能只有几千条。这种情况下Index Merge需要扫描大量中间数据，合并去重后再回表，性能远不如直接走其中一个选择性更高的索引加过滤。

第二个性能瓶颈是合并操作本身的开销。Index Merge需要在内存中维护多个结果集的指针或行标识，然后执行合并算法。对于Intersect合并，需要对多个有序结果集执行多路归并，时间复杂度与各结果集的长度之和成正比；对于Union合并，还需要去重，通常借助哈希表实现，内存消耗与结果集大小成正比。当结果集较大时，合并操作可能成为整个查询中最耗时的环节。相比之下，单索引扫描后直接在内存中逐行过滤，虽然也需要CPU计算，但避免了多路归并和哈希去重的额外开销，在很多场景下反而更快。

第三个容易被忽视的问题是随机I/O的放大效应。走单条索引时，回表操作虽然也是随机I/O，但由于行是按索引顺序访问的，操作系统和存储层可以通过预读机制做一定程度的优化。而Index Merge由于需要从多个不同索引中取数据，这些索引的物理存储顺序可能完全不同，导致回表时的磁盘寻道更加随机，预读效果大幅降低。在机械硬盘上这种差异尤为明显，即便在固态存储上，随机访问的延迟差异依然存在。

那么Index Merge在什么场景下确实有优势？答案是当每个条件的选择性都很高，且结果集很小的时候。比如一张订单表上有订单状态和创建时间两个索引，查询条件是状态等于已完成且创建时间在最近一天之内。如果已完成的订单只占总订单的百分之五，最近一天的订单也只占百分之五，那么分别走这两个索引扫描出的行数都很少，合并后的结果集也很小，回表代价可控，此时Index Merge的总成本确实可能低于走单索引。另一个典型场景是当查询的所有列都被索引覆盖时，Index Merge完全不需要回表，此时合并开销就是主要成本，如果结果集足够小，性能可以非常出色。这也是为什么在某些只需要返回索引列的分析型查询中，Index Merge的表现会明显优于预期。

与Index Merge相比，复合索引在大多数多条件查询场景下依然是最优解。复合索引将多个条件的过滤能力合并到一棵B树中，扫描时一次性完成所有条件的判断，不存在回表放大和合并开销的问题。但复合索引的局限性在于它只能服务于前缀匹配的查询模式，如果查询条件经常变化，维护大量复合索引的成本会很高。此时优化器可能被迫在单索引加过滤和Index Merge之间做选择，而这个选择往往不够准确。

从优化器的决策逻辑来看，选择Index Merge通常发生在以下条件同时满足时：每个单列索引的选择性都较高，复合索引不存在或不被考虑，统计信息显示各索引扫描的行数乘积不会太大。但这里有一个关键的统计学陷阱：优化器基于直方图和采样数据估算行数，在数据分布不均匀时，估算值可能与真实值相差数倍。如果某个条件的实际选择性远低于统计信息显示的值，Index Merge的实际代价就会远超预期。这就是为什么同样的查询在测试环境和生产环境中可能表现截然不同的根本原因。

在实际调优中，面对Index Merge有几条明确的策略。第一，如果执行计划中出现了Index Merge，首先检查是否可以通过添加复合索引来消除它，这是最根本的解决方案。第二，如果无法添加复合索引，尝试通过调整查询条件的顺序或使用提示来强制优化器走选择性更高的单索引，让过滤操作在索引层面完成更多工作。第三，如果查询的返回列可以被某个索引覆盖，考虑重写查询只返回这些列，使Index Merge变为纯索引扫描，避免回表。第四，定期更新统计信息，确保优化器的成本估算尽可能接近真实情况。在某些极端场景下，如果数据分布长期稳定且Index Merge确实表现良好，也可以保留这种执行计划，不必强行干预。

还有一个值得深入讨论的话题是Index Merge与全表扫描的对比。在某些条件下，当所有可用索引的选择性都很低时，优化器可能会选择全表扫描而不是Index Merge。这是因为全表扫描是顺序I/O，在大数据量场景下，顺序读取的吞吐量远高于多个随机索引扫描加回表的总和。一个经典的判断标准是：当需要通过索引回表的行数超过全表总行数的一定比例时，全表扫描反而更快。这个比例通常在百分之二十到百分之三十之间，具体取决于硬件配置和数据分布。Index Merge的问题在于，它试图同时利用多个索引的选择性优势，但当每个索引的选择性都不够高时，多个低效扫描的叠加效果往往还不如一次全表扫描。

从工程实践的角度看，Index Merge是优化器在信息不完备时做出的一种保守选择。它试图在没有完美方案的情况下找到一个次优解，但次优解和真正的最优解之间可能存在巨大的性能鸿沟。作为开发工程师，理解这一点的价值在于：当看到执行计划中出现Index Merge时，不应该盲目接受，而应该将其视为一个信号，提示当前的索引设计或查询写法可能存在优化空间。真正高效的数据库应用，应该尽量让优化器在复合索引和单索引加过滤这两条清晰的路径中做选择，而不是让它在多个不够理想的方案中勉强拼凑。

归根结底，Index Merge不是一个坏的策略，但它是一个容易被高估的策略。在索引设计合理、统计信息准确、数据分布均匀的理想环境下，它能在特定场景中发挥价值；但在真实的生产环境中，数据倾斜、统计偏差、回表放大等因素会让它的表现大打折扣。与其依赖优化器在Index Merge和其他路径之间做赌博式的选择，不如从源头上通过合理的索引设计和查询优化，让执行计划走上更确定、更可控的路径。性能优化的最高境界，不是让优化器做出正确的选择，而是让正确的选择变得唯一。