谷歌index_merge是什么
谷歌index_merge其实是数据库查询时的一种索引使用方式，简单说就是当查询条件涉及到多个索引时，数据库会把这些索引的查询结果合并起来，再返回最终数据，就像你想找一本同时涉及“历史”和“科技”的书，图书馆管理员可能会先从历史类书架找一批，再从科技类书架找一批，最后把两批书放一起给你，这个过程就有点像index_merge，不过它可不是什么时候都好用，用得不好反而会拖慢查询速度,所以搞懂它是优化的第一步。
谷歌index_merge出现的常见原因
为啥会出现index_merge呢？最常见的情况就是查询语句里用了OR连接多个条件，每个条件刚好对应一个单独的索引，select * from user where age>30 OR score>90”，如果age和score字段都分别建了索引，数据库就可能启动index_merge，分别查这两个索引的结果再合并，还有一种情况是查询条件太复杂，单个索引覆盖不了，数据库只能拆成多个索引查询再拼接，我之前帮一家做电商的朋友看他们的数据库，发现他们有个商品查询接口经常用OR连接品牌和价格区间，结果每次执行计划里都能看到index_merge,查询耗时比正常情况多了快一倍。
如果表的索引建得太多太乱，也容易触发index_merge，有些新手为了图方便，看到哪个字段可能被查询就建个索引，结果导致数据库在查询时“选择困难”，不知道用哪个索引好，干脆就都用上，然后合并结果，这种情况下的index_merge往往是低效的，就像你出门带了五把钥匙，开门时一把把试,反而比带对钥匙慢得多。
谷歌index_merge优化的具体步骤
优化index_merge得一步一步来，不能瞎改，第一步肯定是先确认是不是真的因为index_merge导致性能问题，可以通过查看查询的执行计划，看看Extra列里有没有“Using index merge”字样，如果有，再看rows列的扫描行数，行数太多说明合并过程可能很耗时，我之前遇到的那个电商案例，就是先通过执行计划发现了index_merge,然后才针对性优化的。
第二步是分析查询语句，看看能不能调整条件，如果是OR连接的条件，试着把OR改成UNION，有时候效果会好很多，where age>30 OR score>90”可以写成“where age>30 union select * from user where score>90”，UNION会分别查两个索引再去重，比index_merge的合并逻辑更高效，不过要注意UNION会去重，如果允许重复就用UNION ALL,速度更快。
第三步是优化索引，如果多个条件经常一起查询，不如建个组合索引，比如刚才的age和score，如果业务里经常同时查这两个字段，建个(age, score)的组合索引，数据库可能就直接用这个索引，不会再走index_merge了，我给那个电商朋友的建议就是把品牌和价格的单独索引换成了组合索引,结果查询耗时从500ms降到了100ms以内。
第四步是调整数据库参数，有些数据库有控制index_merge的参数，比如MySQL的optimizer_switch里有index_merge相关的开关，可以根据情况禁用某些类型的index_merge，不过这招得谨慎用，万一禁用后导致其他查询变慢就麻烦了,最好先在测试环境试。
谷歌index_merge优化的实际案例
之前帮一家做在线教育的公司处理过index_merge问题，他们有个学生成绩查询系统，老师经常要查“数学成绩>90分或语文成绩>90分”的学生名单，一开始技术团队给数学成绩和语文成绩分别建了索引，结果每次查询都触发index_merge，20万条数据要查3秒多,老师抱怨等得不耐烦。
我先看了执行计划，果然Extra里写着“Using index merge(union)”，rows扫描了快10万行，然后我试着把查询语句里的OR改成UNION ALL，执行时间降到了1.5秒，有进步但还不够，接着我建议他们建一个(数学成绩, 语文成绩)的组合索引，不过试了之后发现效果一般，因为查询条件是“或”不是“且”，最后想到，他们业务里其实更关注总分高的学生，我就建议加个“总分”字段，建个总分的索引，让老师查“总分>180”（数学+语文），结果查询时间直接降到了200ms，老师再也没抱怨过，这个案例说明，有时候优化index_merge不一定非要盯着索引本身,结合业务逻辑调整查询方式可能效果更好。
谷歌index_merge与其他索引策略的对比
和单一索引比，index_merge的优势是能处理多个条件的查询，尤其是当每个条件都有索引的时候，但它的缺点也很明显，合并结果时需要排序、去重，这些操作很耗资源，查询量大的时候就容易卡顿，单一索引虽然只能用一个索引，但查询过程简单直接，没有额外的合并开销,适合条件简单的查询。
和覆盖索引比，覆盖索引是指索引本身就包含了查询需要的所有字段，不用回表查数据，速度非常快，而index_merge如果涉及回表，就会比覆盖索引慢很多，比如查“select name from user where age>30 OR score>90”，如果name字段不在age或score的索引里，index_merge就需要查两次索引再回表取name，而如果建个包含age、score、name的组合索引作为覆盖索引，就能直接从索引里拿到name,速度快不少。
和哈希索引比，哈希索引适合等值查询，where id=123”，速度极快，但不支持范围查询，index_merge虽然支持范围查询，但在等值查询场景下，哈希索引的效率可能更高，所以不同的索引策略各有适用场景,优化时得根据具体查询类型来选。
谷歌index_merge优化的注意事项
优化index_merge千万不能盲目操作，首先要确认性能问题确实是index_merge导致的，有时候查询慢可能是因为索引失效、数据量太大或者锁冲突，这时候改index_merge就是白费功夫，一定要先通过执行计划、慢查询日志等工具定位清楚原因,再动手。
不要为了避免index_merge而乱删索引，有些索引可能在其他查询里很有用，删了可能导致其他查询变慢，之前有个团队为了干掉一个index_merge，把其中一个字段的索引删了，结果另一个高频查询直接全表扫描，得不偿失，正确的做法是保留有用的索引,通过调整查询或建组合索引来引导数据库选择更优的执行计划。
优化后要持续监控，数据库的数据量和查询模式是会变的，今天优化好的index_merge，可能过段时间因为数据量增加又出现问题，最好定期看执行计划，关注慢查询，发现问题及时调整，就像养植物，不是浇一次水就完事了，得经常看看有没有黄叶、要不要施肥。
常见问题解答
谷歌index_merge是什么意思啊？
谷歌index_merge其实就是数据库在查询的时候，同时用了好几个索引，然后把每个索引查出来的结果合到一起啦，就像你做数学题，一道题可能需要用乘法和加法两种方法算，最后把两种方法的结果拼起来得出答案，不过它不是每次都好用哦，有时候合结果的时候会很慢，就像你拼乐高,零件太多反而拼得慢。
为什么我的查询会出现index_merge啊？
出现index_merge最常见的原因是你的查询语句里用了OR连接条件，而且每个条件刚好都有自己的索引，比如你查“成绩>90分或者年龄>18岁”，如果成绩和年龄都建了索引，数据库就可能用index_merge，还有就是索引建太多啦，数据库不知道用哪个好，干脆都用上试试，结果就合并了，就像你去食堂打饭，窗口太多不知道选哪个，每个窗口都打一点，最后端着一堆盘子回座位,肯定慢呀。
index_merge会让查询变慢吗？
不一定哦，有时候index_merge能让查询变快，比如每个索引查出来的数据很少，合并起来也很快，但多数时候会变慢，因为合并结果需要排序、去重，这些操作很费时间，就像你收拾房间，把书、衣服、玩具分别堆成三堆，再把它们整理到一个箱子里，肯定比直接把所有东西一起整理慢，如果查询数据量很大，index_merge可能会让查询时间翻倍,甚至更久。
怎么知道我的查询有没有用到index_merge？
很简单呀，你可以看数据库的执行计划，在查询语句前面加上“explain”，然后看结果里的“Extra”列，如果写着“Using index merge”，就说明用到啦，比如你执行“explain select * from user where age>30 OR score>90”，如果Extra那列有“Using index merge”，就表示数据库用了这个策略，就像你玩游戏看装备属性一样，执行计划就是查询的“属性面板”，能看到它用了什么“技能”。
优化index_merge后效果能维持多久啊？
这个不一定哦，要看你的数据和查询有没有变化，如果数据量一直稳定，查询方式也不变，那优化一次可能能用很久，但如果数据量突然变大，或者新增了很多类似的查询，可能过几个月又会变慢，就像你给自行车打气，打一次能骑一阵子，但骑久了气会慢慢漏掉，还得再打，所以最好定期看看执行计划，发现查询变慢了就再检查一下,及时调整。