在用数据库处理大量数据时，经常会遇到查询变慢的问题。比如你在一家电商公司负责订单系统，老板突然问你：‘能不能查出2023年11月下单，又在12月复购的用户？’这种多条件组合的查询，单靠一个字段的索引可能效果不好，这时候就得考虑索引合并了。
什么是索引合并？
简单说，索引合并（Index Merge）是数据库优化器的一种策略。当一条查询涉及多个字段，而每个字段都有自己的索引时，数据库可以分别用这些索引找出符合条件的数据行，再把结果合并起来，而不是全表扫描。
比如你的订单表有两个索引：一个是 create_time，另一个是 user_id。你想查某个时间段内某批用户的订单，数据库就可以先用时间索引圈出一批记录，再用用户索引圈出另一批，最后取它们的交集。
常见的使用场景
最典型的场景就是“多条件OR查询”。假设你做的是社区平台，要查出所有发过帖子或者评论过的用户：
SELECT user_id FROM actions WHERE post_count > 0 OR comment_count > 0;如果 post_count 和 comment_count 各自建了索引，MySQL 就可能使用索引合并，分别查出两个结果集，然后合并去重。这样比扫整张表快得多。
另一个常见情况是复合查询但没建联合索引。比如你有个用户表，有性别、年龄、城市三个字段的独立索引。运营想查“北京的女性用户，年龄在25岁以上”：
SELECT * FROM users WHERE city = '北京' AND gender = '女' AND age > 25;如果你没建 (city, gender, age) 的联合索引，数据库也可能启用索引合并，从三个索引各自找数据，再取交集。
什么时候该注意？
虽然索引合并能救急，但它不是万能药。它的合并过程本身有开销，特别是取并集时要做排序去重。有时候还不如直接建个联合索引来得干脆。
比如上面那个三条件查询，如果经常这么查，不如直接加个联合索引：
ALTER TABLE users ADD INDEX idx_city_gender_age (city, gender, age);这样一来，查询可以直接走这个索引，效率更高，还省了合并步骤。
另外，某些数据库比如老版本 MySQL 对索引合并的支持有限，可能会误判成本导致选错执行计划。这时候可以通过 FORCE INDEX 或改写 SQL 来引导优化器。
实际建议
日常开发中，如果发现某条查询走了 index merge（可以用 EXPLAIN 看执行计划），别慌。先看看是不是缺失了合适的联合索引。如果有高频查询组合，优先建联合索引；如果是低频或临时查询，索引合并反而能省下维护多余索引的成本。
就像家里收拾东西，常用的东西放抽屉里顺手拿，偶尔才用的就收箱子里——索引也一样，合理利用才能既快又轻。”}