Index Merge MySQL

索引合并查询优化是MySQL5.0引进的.

 通常情况下.针对单独表的查询，我们仅仅只能使用其中一个索引来完成数据行检索。

 但合并索引查询，是通一个表上几个索引范围查询，然后在合并结果一个方式。

 1.针对于单表查询

 2.结果集可以union或是insertsection或是union_of_insertsection

 3.就是大表化零的思想应用.通过各个索引查询出来小点结果，然后根据条件合并结果集。

 效率不一定就是有多高.

  比如扫描是1.

  通过三个索引扫描分别是01,03,04那么总结果是01+03+04<1这样效率高于全表扫描，但还有一次合并操作.所以这样结果

  可能有所提高，但在某此情况下，肯定是不能提高多少的.可能还低!不如全表扫描.[待验证，如何排除效率低下的情况]

基本验证了上面的想法，只要是两个索引，都可以走index_merge，换成三个马上就不行了，即使是强行指定用某两个索引也不行，索引都能够认到，但优化器就是不使用任何一个。想一下，如果按照提示，使用了两个索引，那么会有剩下一个条件不会走索引，那么对于该条件的过滤还是要通过表查询，这样，对于 mysql来说就相当于要两个索引的index_mereg后再读表，而且仍然要做一次全表扫描，那还不如就作一次表扫描，Mysql最终还是选择一次表扫描是可以理解的。在Mysql文档上面也说了，在提示了mysql用某一个索引后，也就相当于告诉了mysql不要用其他的相关的一些索引。估计 Mysql也并没有去实现三个索引的index_merge，实际上想想就算是实现了，通过读三个索引然后做merge再去取表的记录，其消耗可能也并不会太小，对于Mysql的这个选择也无可厚非。

参考：一条Mysql上的Sql优化经历

   当然如果块重复的肯定不会读取两次吧，要不MySQL也太弱智了.有可能就发生内存拷贝或是直接用同一数据块.

 eg:

 mysql> explain select * from test where TEST_ID='89102' or IDLOG='37689'  or CREATETIME='2011-11-11 11:11:11' \G;

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

               table: test

               type: index_merge

 possible_keys: IDX_TEST_ID,IDX_IDLOG,IDX_HIS_CREATETIME

                key: IDX_TEST_ID,IDX_IDLOG,IDX_HIS_CREATETIME

                key_len: 98,8,4

               ref: NULL

               rows: 3

            Extra: Using sort_union(IDX_TEST_ID,IDX_IDLOG,IDX_HIS_CREATETIME); Using where