mysql 索引下推（icp）将部分 where 条件从服务层下推至存储引擎层过滤，仅适用于 innodb 的二级联合索引，且需满足最左匹配前提；启用后可减少回表次数，提升性能，explain 中显示“using index condition”即生效。
MySQL 索引下推（Index Condition Pushdown，简称 ICP）是一种查询优化机制，它把原本在服务层（Server Layer）执行的部分 WHERE 条件，下推到存储引擎层（Storage Engine Layer）去提前过滤，从而减少回表次数和无效数据读取。
索引下推适用的场景
它只在使用 ** 二级索引（非主键索引）**，且查询条件中包含 ** 联合索引的中间或后缀列 ** 时才可能生效。典型前提包括：
- 使用的是 InnoDB 存储引擎（ICP 从 MySQL 5.6 开始支持）
- 查询语句用到了复合索引，比如 (name, age, city)
- WHERE 条件中同时出现最左列（如 name = ‘ 李四 ’）和非最左列（如 city = ‘ 北京 ’），而中间列 age 未参与过滤
- 过滤条件能被索引项直接携带的字段满足（即该字段值已存在于索引 B + 树叶子节点中）
为什么能提升性能
关键在于减少“回表”——也就是避免把大量不满足条件的索引记录拉到主键索引里查完整行。传统方式是：
- 先用索引找到所有 name = ‘ 李四 ’ 的索引项（比如 100 条）
- 再逐条拿着主键 ID 回主键索引取整行，再判断 city = ‘ 北京 ’
启用 ICP 后，流程变成：
- 在扫描索引时，引擎直接检查每个索引项里的 city 值
- 只保留 name = ‘ 李四 ’ AND city = ‘ 北京 ’ 的索引项（比如只剩 3 条）
- 仅对这 3 条做回表，大幅降低 I / O 和 CPU 开销
如何确认是否启用了索引下推
执行 EXPLAIN FORMAT=TRADITIONAL 或 EXPLAIN FORMAT=JSON，观察执行计划：
- 如果 Extra 列出现 Using index condition，说明 ICP 已生效
- 若只有 Using where，则过滤仍在 Server 层完成，未下推
- 注意：即使有复合索引，若查询条件跳过最左列（如只查 city = ‘ 北京 ’），索引本身都用不上，更谈不上 ICP
哪些条件无法下推
不是所有 WHERE 子句都能下推，ICP 只支持存储引擎能直接计算的简单条件：
- ✅ 支持：等值（=）、范围（>, BETWEEN）、LIKE ‘ 前缀 %’ （非通配符开头）
- ❌ 不支持：函数调用（如 UPPER(name) = ‘LI SI’）、子查询、涉及非索引列的表达式、全文检索、空间函数等
- ⚠️ 注意：即使字段在索引中，若类型隐式转换（如字符串索引列与数字比较），也可能导致 ICP 失效
