有负面效应。当表的数据量很小，大部分数据也都被缓存的时候，使用MRR不会带来随机访问的收益，反而会因为额外的排序操作增加资源消耗；当限制只需要返回LIMIT n的时候，这种优化会读取排序很多不需要的索引，性能反而会降低；排序使用的内存空间大小由mrr_buffer_size设定的，如果该内存较小但是待排序的索引数量大的时候，就需要使用磁盘辅助进行多块排序归并，这也会降低性能。
6. Index Condition Pushdown(ICP)优化
老旧数据库版本只有索引可用的限制条件才会被传输到存储引擎层，在新版本开启ICP优化的时候，针对选用索引涉及到的数据列条件就都会被传输到存储引擎层，所以在支持ICP特性后，存储引擎在处理索引的同时就可以判断是否可以通过下推的选择条件对部分记录直接进行过滤操作了。所以在老版本的数据库，都是存储引擎对索引可以直接使用的条件进行操作，然后再将这些数据传递给MySQL引擎，这样就会涉及到大量数据条目的读取、传递和筛选工作，这时候在Extra中肯定会看到Using where的提示，因为MySQL引擎对存储引擎传递来的数据进行了筛选加工；现在将索引涉及到的筛选条件下推放到了存储引擎层，就大大减少了上面的操作任务。
该功能可以使用SET optimizer_switch=’index_condition_pushdown=on|off’的方式打开或者关闭。ICP优化可以用于range、ref、req_ref、ref_or_null类型的查询，当查询使用到该特性的时候可以在Extra看到Using index condition。
7. 索引合并
当查询WHERE中罗列有多个条件，他们都可以使用不同的索引进行优化查询的时候，如果优化器发现某一个索引返回的记录相比其他索引显著的要少，那么执行计划就会选用这个索引；而如果优化器发现多个索引都不高效的时候，优化器会将这些查询条件分离，用各自的索引分别独立执行检索，最后再将多个结果集合进行合并后返回。当然，这种情况优化器也可能使用全表扫面的方式处理。
本文完！
参考