索引下推（ICP）是MySQL 5.6+自动启用的优化机制，核心是将WHERE中可由索引列判断的条件下推至存储引擎层过滤，减少回表次数；EXPLAIN出现“Using index condition”即表示生效，否则仍全量回表。
索引下推（ICP）不是“要不要用”的问题，而是只要满足条件，MySQL 5.6+ 就会自动启用——你无法手动开启或关闭它，但能通过索引设计和查询写法决定它是否生效。关键在于：ICP 能否被触发，直接决定了回表次数是“全量扫描索引后回表”，还是“只对真正可能命中的索引记录回表”。
为什么 EXPLAIN 出现 Using index condition 才算 ICP 生效
这是唯一可靠的判断依据。它出现在 Extra 列里，表示 Server 层把部分 WHERE 条件下推给了 InnoDB 引擎层执行过滤。
- 没出现时（比如只有
Using where），说明所有索引列的过滤都留在 Server 层，引擎扫完所有匹配最左前缀的索引项后，全量回表，再由 Server 逐行过滤 - 出现
Using index condition，意味着引擎在遍历索引页时，已用索引字段做了初步筛选，只把主键 ID 交给 Server 层回表 - 注意：
Using index（覆盖索引）和Using index condition完全不同——前者根本不需要回表，后者仍要回表，只是回得少
name LIKE '张%' 后面的 age = 25 能触发 ICP，但 age > 25 不一定
联合索引 idx_name_age(name, age) 下，name 是等值或范围查找的起点，age 是“范围之后的索引列”。ICP 能利用这部分字段过滤，但效果取决于条件类型：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
WHERE name LIKE '张%' AND age = 25→age = 25可下推，ICP 生效 -
WHERE name LIKE '张%' AND age BETWEEN 20 AND 30→ 范围条件也可下推，InnoDB 支持对索引字段做范围判断 -
WHERE name = '张三' AND age > 18→ 同样可下推；但若写成WHERE name > '张'（name 本身是范围），则age仍可 ICP，因为 ICP 不要求前面必须是等值，只要它是索引的一部分且未被用于定位起点即可 - 不能下推的典型：涉及函数、类型转换、子查询，如
WHERE UPPER(name) = 'ZHANG'或WHERE age + 1 = 26
联合索引顺序错了，ICP 就失效
ICP 依赖“索引中存在该字段”，但更依赖字段在索引中的位置是否允许被下推。常见误判是认为“只要字段在联合索引里就能用 ICP”，其实不然：
- 索引
idx_age_name(age, name)，查询WHERE name = '张三' AND age = 25→name不是最左前缀，索引根本用不上，ICP 无从谈起 - 索引
idx_city_status(city, status)，查询WHERE city = '北京' AND status IN (1,2,3)→status是等值列表，ICP 可生效；但如果写成WHERE status = 1 AND city = '北京'，优化器仍可能选对索引，但需确认EXPLAIN中key是否为idx_city_status，否则 ICP 不触发 - 主键索引（聚簇索引）不支持 ICP —— 因为它不涉及回表，ICP 的优化目标（减少回表）不存在
ICP 对性能的影响不是线性的，数据分布越倾斜收益越大
假设一个用户有 10 万条订单，其中 99% 是 order_status = 0（待支付），只有 1% 是 order_status = 1（已支付）。联合索引 idx_user_status(user_id, order_status) 下：
- 无 ICP：InnoDB 扫出全部 10 万条
user_id = X的索引记录 → 10 万次回表 → 大量无效 IO - 有 ICP：引擎在索引页内直接丢弃
order_status != 1的记录 → 约 1000 次回表 → IO 降低两个数量级 - 但如果数据均匀（比如 status 0/1 各占 50%），ICP 仍生效，但收益只减半；此时更应优先考虑覆盖索引（如
SELECT user_id, order_status FROM ...）彻底避免回表
最容易被忽略的一点：ICP 的收益完全依赖于索引字段的区分度和查询条件的选择性。建索引时只看“能不能走索引”远远不够，必须结合实际查询模式，预判哪些字段大概率作为“范围后的过滤项”参与 ICP —— 这才是联合索引排序的真实依据。
