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' 这类无法利用索引排序的模式）。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 支持下推的条件类型：
=、>、、<code>BETWEEN、IN（单值）、IS NULL - 不支持下推：
LIKE '%abc'（前导通配）、!=、OR多分支、涉及函数的表达式（如UPPER(name)） - 注意：即使
age在索引中，若写成age + 1 > 26，也会因表达式计算失去下推能力
UPDATE JOIN 场景下 ICP 容易失效，需特别验证
多表 UPDATE ... JOIN 时，ICP 是否生效取决于驱动表使用的索引类型和条件分布。常见陷阱是右表（JOIN 表）的过滤条件被误认为可下推，但实际上 MySQL 通常只对驱动表的二级索引应用 ICP，被驱动表的条件仍由 Server 层过滤。
- 用
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 开关。
