区分 UPDATE 必须读取并修改完整记录与 SELECT 的索引条件下推显示

上周排查线上慢查询，我盯着一条UPDATE的执行计划愣了半天，明明建了符合条件的联合索引，为啥走索引还扫了全量的聚簇索引记录，同查询条件的SELECT明明能正常触发索引条件下推，扫描行数少了一大半，踩完坑才把两个操作的底层行为差异理清楚。

我在排查一条 UPDATE 的执行计划时，最容易先入为主地盯住 Extra：为什么 SELECT 似乎能做索引条件下推，UPDATE 却看不到 Using index condition？结论是，这不等于 UPDATE 没有使用索引，也不等于索引失效。SELECT 和 UPDATE 的目标不同：前者尽量减少无效的完整行读取，后者必须取得目标记录并完成修改。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/index-condition-pushdown-optimization.html

Index Condition Pushdown（ICP）解决的是“读完整行之前，能否先用索引列淘汰候选”的问题；UPDATE 还要读取并修改目标记录、维护相关索引，所以不能拿 SELECT 的 Extra 文案直接套在 UPDATE 上。

先看两个语句解决的问题不同

MySQL 8.4 文档对 ICP 的描述很明确：存储引擎先拿到索引条目，用索引中的列检查可下推的 WHERE 条件，条件满足后才读取完整表记录。这样节省的是不必要的回表读取。

但 UPDATE 的终点不是“返回几列”。即使 WHERE 条件由二级索引定位，InnoDB 仍需要取得聚簇记录，读取当前值，写入被修改的列，并处理受影响的索引一致性。对 UPDATE 来说，完整记录不是可选的附带信息，而是数据变更的对象。

因此，看到 UPDATE 的 Extra 没有 Using index condition，先不要把它解释成“没有走索引”。先看 key 是否选中了预期索引、type 是否为合理的访问方式、rows 估算是否异常，再判断是否真的存在扫描问题。

用同一组条件对比 EXPLAIN

准备一个订单表，联合索引负责先按状态和客户号定位。下面的 SQL 只用于展示 EXPLAIN 的观察方式；注释说明了每段的目的。

-- 联合索引把状态放在前面，再保留客户号供范围定位
CREATE INDEX idx_orders_status_customer
ON orders (status, customer_id);

-- SELECT 需要返回完整订单行，便于观察索引条件与回表边界
EXPLAIN SELECT *
FROM orders
WHERE status = 'PAID'
  AND customer_id LIKE 'A%';

-- UPDATE 使用同一组筛选条件，但最终必须修改目标记录
EXPLAIN UPDATE orders
SET note = '已归档'
WHERE status = 'PAID'
  AND customer_id LIKE 'A%';

对 SELECT 来说，如果访问方式和存储引擎满足条件，Extra 可能出现 Using index condition：索引先筛掉不符合索引条件的候选，再读取完整行。对 UPDATE 来说，计划可能只显示 Using where 或其他与变更路径有关的提示；这并不能单独证明索引没有参与定位。

这里要特别区分两个词：Using index condition 指的是 ICP，强调“把一部分 WHERE 判断交给存储引擎”；而 Using index 是另一个 Extra 提示。本文只讨论 UPDATE 与 ICP 的适用边界，不把两个提示混成同一件事。

为什么 UPDATE 不能只拿索引条目完成修改

我实际排查时，最有用的思路是把 UPDATE 拆成“定位”和“写入”两块，而不是只看它是否复现了 SELECT 的 Extra。二级索引可以帮助 WHERE 找到候选，但被修改的列、当前行版本和写入后的索引状态仍属于记录变更职责。

所以，“UPDATE 必须读取完整记录”与“SELECT 可以在完整行读取前做 ICP”并不矛盾。它们关注的是同一次访问中的不同阶段：SELECT 的收益是少读一些不需要返回的完整记录；UPDATE 只要确定要改哪一行，就不能跳过写入所需的记录读取。

排查 UPDATE 是否真的有问题

遇到这种计划差异，我会按下面的最小配方检查，而不是为了让 Extra 出现某个词去改 SQL：

1. 先确认 key 是否为预期索引，possible_keys 只是候选，不代表最终使用。
2. 再看 type、key_len 和 rows，判断是否用上了联合索引的有效前缀以及扫描估算。
3. 确认表引擎和索引类型。MySQL 文档对 InnoDB 的 ICP 说明重点在二级索引，聚簇索引本身已经包含完整记录。
4. 如果怀疑开关被改过，再查看当前会话的优化器设置；不要把检查开关当成强制 UPDATE 显示该 Extra 的办法。

-- 只读取当前会话的优化器开关，确认 ICP 是否被关闭
SELECT @@optimizer_switch;

-- 需要做对照时，在当前会话显式打开 ICP；不要改成全局设置
SET SESSION optimizer_switch = 'index_condition_pushdown=on';

-- 重新查看变更语句的访问路径，重点比较 key、type、rows 和 Extra
EXPLAIN UPDATE orders
SET note = '已归档'
WHERE status = 'PAID'
  AND customer_id LIKE 'A%';

最后还要看 WHERE 条件是否真的有选择性、统计信息是否陈旧，以及更新列是否参与索引维护。即使这些都正常，UPDATE 没有显示 Using index condition 仍可能是合理计划。判断标准应是访问路径和实际写入代价，而不是让查询和变更语句共享一套 Extra 文案。

相关问题

UPDATE 没有 Using index condition 就是全表扫描吗？

不是。先看 key、type 和 rows。Extra 缺少某个优化提示，不能替代对访问类型的判断。

SELECT 和 UPDATE 必须得到完全相同的执行计划吗？

不必。两者一个负责读取结果，一个负责修改记录；即使 WHERE 相同，优化器也会根据语句目标选择不同的访问和变更路径。