在 ICP 优化开启时，在存储引擎端首先用索引过滤可以过滤的 where 条件，然后再用索引做 data access，被 index condition 过滤掉的数据不必读取，也不会返回 server 端。
举例比如：
SELECT * FROM employees WHERE first_name='Mary' AND last_name LIKE '%man';在没有 ICP 时，首先通过索引前缀从存储引擎中读出所有 first_name 为 Mary 的记录，然后在 server 端用 where 筛选 last_name 的 like 条件；
而启用 ICP 后，由于 last_name 的 like 筛选可以通过索引字段进行，那么存储引擎内部通过索引与 where 条件的对比来筛选掉不符合 where 条件的记录，这个过程不需要读出整条记录，同时只返回给 server 筛选后条记录，因此提高了查询性能。
注意事项有几个关于ICP的事情要注意：
ICP 只能用于二级索引，不能用于主索引；
也不是全部 where 条件都可以用 ICP 筛选，如果某 where 条件的字段不在索引中，当然还是要读取整条记录做筛选，在这种情况下，仍然要到 server 端做 where 筛选；
ICP 的加速效果取决于在存储引擎内通过 ICP 筛选掉的数据的比例；
总结建索引的几大原则1、最左前缀匹配原则，非常重要的原则，MySQL 会一直向右匹配直到遇到范围查询 （>、<、between、like）就停止匹配；
2、= 和 in 的条件可以乱序；
3、尽量选择区分度高的列作为索引，区分度表示字段不重复的比例，比例越大我们扫描的记录数越少；
4、索引列不能参与计算，保持列「干净」。原因很简单，b+ 树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。
5、尽量的扩展索引，不要新建索引。
索引是最好的解决方案吗？
索引不是最好的，但已经是相当好的了。
当表非常小时，没必要使用索引，直接全表查询好了；
当表是中大型时，比较适合使用索引，来快速定位目标数据；
当表是超大型时，创建和维护索引都是不小的代价，需要专业的 DBA 来分析，这种情况下可以尝试使用分表技术；
参考：
https://blog.csdn.net/u012006689/article/details/73195837
最近搜集到传智播客 2018 最新 Python 和 Java 教程！关注本公众号，后台回复「2018」即可获取下载地址。
> 公众号提供CSDN资源免费下载服务！