比如 a = 1 and b = 2 and c > 3 and d = 4 如果建立 (a,b,c,d) 顺序的索引，d 是用不到索引的，如果建立 (a,b,d,c) 的索引，则都可以用到，a,b,d 的顺序可以任意调整。
3、= 和 in 的条件可以乱序
MySQL 的查询优化器会帮你优化成索引可以识别的形式。MySQL 查询优化器会判断纠正 SQL 语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。
为什么要使用联合索引？1、 减少开销
"一个顶三个"。建一个联合索 引(col1,col2,col3)，实际相当于建了 (col1),(col1,col2),(col1,col2,col3) 三个索引。
每多一个索引，都会增加写操作的开销和磁盘空间的开销。对于大量数据的表，使用联合索引会大大的减少开销！
2、 覆盖索引
对联合索引 (col1,col2,col3)，如果有如下的sql: select col1,col2,col3 from test where col1=1 and col2=2。那么 MySQL 可以直接通过遍历索引取得数据，而无需回表，这减少了很多的随机 IO 操作。
减少 io 操作，特别的随机 io 其实是 dba 主要的优化策略。所以，在真正的实际应用中，覆盖索引是主要的提升性能的优化手段之一。
3、 效率高
索引列越多，通过索引筛选出的数据越少。
有 1000W 条数据的表，有如下sql: select col1,col2,col3 from table where col1=1 and col2=2 and col3=3，假设假设每个条件可以筛选出 10% 的数据。
如果只有单值索引，那么通过该索引能筛选出 1000W_10%=100w 条数据，然后再回表从 100w 条数据中找到符合 col2=2 and col3= 3 的数据，然后再排序，再分页；
如果是联合索引，通过索引筛选出 1000w_10% * 10% *10%=1w，效率提升可想而知！
索引下推索引条件下推（ICP：index condition pushdown）是 MySQL 中一个常用的优化，尤其是当 MySQL 需要从一张表里检索数据时。
ICP（index condition pushdown）是 MySQL 利用索引（二级索引）元组和筛字段在索引中的 WHERE 条件从表中提取数据记录的一种优化操作。
ICP 的思想是：存储引擎在访问索引的时候检查筛选字段在索引中的 where 条件，如果索引元组中的数据不满足推送的索引条件，那么就过滤掉该条数据记录。
ICP（优化器）尽可能的把 index condition 的处理从 server 层下推到存储引擎层。
存储引擎使用索引过滤不相关的数据，仅返回符合 index condition 条件的数据给 server 层。也是说数据过滤尽可能存储引擎层进行，而不是返回所有数据给 server 层，然后后再根据 where 条件进行过滤。
下推过程优化器没有使用 ICP 时
数据访问和提取的过程如下：
①：MySQL Server 发出读取数据的命令，调用存储引擎的索引读或全表表读。此处进行的是索引读。
②、③：进入存储引擎，读取索引树，在索引树上查找，把满足条件的（红色的）从表记录中读出（步骤 ④，通常有 IO）。
⑤：从存储引擎返回标识的结果。
以上，不仅要在索引行进行索引读取（通常是内存中，速度快。步骤 ③），还要进行进行步骤 ④，通常有 IO。
⑥：从存储引擎返回查找到的多条数据给 MySQL Server，MySQL Server 在 ⑦ 得到较多的元组。
⑦--⑧：依据 WHERE 子句条件进行过滤，得到满足条件的数据。
注意在 MySQL Server 层得到较多数据，然后才过滤，最终得到的是少量的、符合条件的数据。
在不支持 ICP 的系统下，索引仅仅作为 data access 使用。
优化器使用ICP时
①：MySQL Server 发出读取数据的命令，过程同图一。
②、③：进入存储引擎，读取索引树，在索引树上查找，把满足已经下推的条件的（红色的）从表记录中读出（步骤 ④，通常有 IO）；
⑤：从存储引擎返回标识的结果。
此处，不仅要在索引行进行索引读取（通常是内存中，速度快。步骤 ③），还要在 ③ 这个阶段依据下推的条件进行进行判断，不满足条件的，不去读取表中的数据，直接在索引树上进行下一个索引项的判断，直到有满足条件的，才进行步骤 ④ ，这样，较没有 ICP 的方式，IO 量减少。
⑥：从存储引擎返回查找到的少量数据给 MySQL Server，MySQL Server 在 ⑦ 得到少量的数据。
因此比较图一无 ICP 的方式，返回给 MySQL Server 层的即是少量的、 符合条件的数据。
