MySQL UPDATE语句在满足条件时可触发索引下推（ICP）：需使用二级索引、WHERE条件含索引覆盖列、访问类型为range/ref，且EXPLAIN显示“Using index condition”。

MySQL 的 UPDATE 语句本身不直接触发索引下推（ICP），但只要其 WHERE 条件中包含可下推的索引列，且满足 ICP 启用条件，ICP 就会在底层扫描阶段生效——这会显著减少回表次数，从而加速 UPDATE 执行。

UPDATE 的 WHERE 条件必须走二级索引才能用上 ICP

ICP 只作用于二级索引（非聚簇索引）扫描过程。如果 UPDATE 使用主键或唯一索引定位单行（如 WHERE id = 123），存储引擎直接定位到聚簇索引叶子节点，无需回表，ICP 无意义；只有当 WHERE 依赖的是普通二级索引（例如 name、(zipcode, name)）时，ICP 才有机会介入。

• 确认执行计划中 type 是 range 或 ref，且 key 显示用了二级索引
• Extra 列出现 Using index condition，才是 ICP 生效的明确信号
• 若 Extra 是 Using where，说明过滤全在 Server 层做，没下推

联合索引中非最左字段的条件可能被下推，但有严格限制

比如有联合索引 idx_name_age (name, age)，执行 UPDATE user SET status = 1 WHERE name = '张三' AND age > 25，其中 age > 25 就是典型的可下推条件：它虽不是最左前缀，但属于索引已覆盖的字段，且满足范围/等值判断（不支持 LIKE '%xx' 这类无法利用索引排序的模式）。

• 支持下推的条件类型：=、>、、BETWEEN、IN（单值）、IS NULL
• 不支持下推：LIKE '%abc'（前导通配）、!=、OR 多分支、涉及函数的表达式（如 UPPER(name)）
• 注意：即使 age 在索引中，若写成 age + 1 > 26，也会因表达式计算失去下推能力

UPDATE JOIN 场景下 ICP 容易失效，需特别验证

多表 UPDATE ... JOIN 时，ICP 是否生效取决于驱动表使用的索引类型和条件分布。常见陷阱是右表（JOIN 表）的过滤条件被误认为可下推，但实际上 MySQL 通常只对驱动表的二级索引应用 ICP，被驱动表的条件仍由 Server 层过滤。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 用 EXPLAIN FORMAT=JSON 查看 join_execution 部分，确认 using_index_condition 出现在哪一层的 access_type 下
• 若右表使用了 ALL 或 index 访问类型，基本可判定 ICP 未对其生效
• 避免在 SET 子句中引用右表未索引字段，否则优化器可能放弃对驱动表的 ICP 优化

ICP 默认开启但可能被 optimizer_switch 全局关闭

即使你的 MySQL 版本 ≥ 5.6，也不能默认认为 ICP 一定启用。生产环境常因兼容性或旧逻辑依赖被手动关闭，必须显式检查。

• 运行 SELECT @@optimizer_switch，搜索 index_condition_pushdown 是否为 on
• 临时开启：SET SESSION optimizer_switch="index_condition_pushdown=on"
• 注意：全局设置需 SET GLOBAL，但会影响所有新连接，上线前务必压测
• 某些云数据库（如阿里云 RDS）可能锁定该开关，需查控制台或工单确认

真正容易被忽略的是：ICP 效果高度依赖数据分布和条件选择性。哪怕 EXPLAIN 显示 Using index condition，如果索引匹配的初始行数极大（比如 name 重复率极高），下推后仍需回表成千上万次，性能提升就微乎其微——这时得回归索引设计本身，而不是只盯着 ICP 开关。