UPDATE语句卡在WHERE条件上是因为未走索引，导致全表扫描、锁等待和CPU飙升；需用EXPLAIN确认执行计划，确保WHERE字段有索引，避免隐式类型转换，并合理使用SELECT FOR UPDATE加锁。
UPDATE语句卡在WHERE条件上，是因为没走索引
高频UPDATE最常卡住的地方不是UPDATE本身，而是WHERE子句查不到索引。数据库得先定位行，再改值；如果WHERE user_id = ?字段没建索引，每次都是全表扫描——并发一高，锁等待、CPU飙升、慢查询日志爆满。
实操建议：
- 用
EXPLAIN UPDATE ...（MySQL 8.0.19+）或先改写成EXPLAIN SELECT *确认执行计划是否走了索引 - 复合条件如
WHERE status = 'pending' AND created_at ，优先把等值列（<code>status）放前面建联合索引，范围列（created_at）放后面 - 避免在WHERE里对字段做函数操作，比如
WHERE DATE(created_at) = '2024-01-01'会失效索引，改成WHERE created_at >= '2024-01-01' AND created_at
批量UPDATE时别用IN (1,2,3,...1000)
用长IN列表更新几百上千行，看似简单，实际容易触发参数长度限制、执行计划不稳定、甚至被优化器误判为全表扫描。PostgreSQL对IN列表有硬限制（默认work_mem相关），MySQL在prepared statement中也可能报Packet too large。
实操建议：
- 拆成每50–100行一批，用循环执行多个
UPDATE ... WHERE id IN (?, ?, ...) - 更稳的方式是用临时表：先
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY)，批量INSERT ID，再UPDATE t SET status = 'done' WHERE t.id IN (SELECT id FROM tmp_ids) - MySQL 8.0+ 或 PostgreSQL 可用
VALUES ROW()语法构造内联数据集，避免建表开销，例如：UPDATE orders SET state = 'shipped' WHERE id IN (SELECT id FROM (VALUES ROW(1), ROW(2), ROW(3)) AS v(id))
SET子句里别碰被WHERE依赖的字段
比如UPDATE accounts SET balance = balance - 100, updated_at = NOW() WHERE user_id = 123 AND balance >= 100——这里WHERE检查balance，SET又修改它。在RC（Read Committed）隔离级别下，可能因MVCC快照不一致导致“幻读式”漏更新；在RR（Repeatable Read）下还可能引发间隙锁冲突，尤其当balance字段无索引时。
实操建议：
- 把校验逻辑前置到应用层：先
SELECT balance FROM accounts WHERE user_id = 123 FOR UPDATE，判断够扣再发UPDATE - 若必须单条SQL完成，确保
balance字段有索引，并使用SELECT ... FOR UPDATE加锁后UPDATE，而不是依赖WHERE中的字段值参与计算 - 避免
SET x = y + 1, y = x + 1这类相互依赖赋值，不同数据库处理顺序不一致，MySQL按从左到右，PostgreSQL按原子快照，结果不可移植
UPDATE影响行数突增，可能是隐式类型转换
某次上线后监控发现UPDATE users SET last_login = NOW() WHERE phone = '13800138000'突然变慢、影响行数从1跳到上万——大概率是phone字段定义为VARCHAR，但传入参数是数字类型（如Java里用了Long），触发MySQL隐式转换：索引失效，且整列转数字比对，大量字符串被强制转0或截断。
实操建议：
- 用
SHOW WARNINGS查执行后的警告，出现Warning | 1292 | Truncated incorrect DOUBLE value就是典型征兆 - 统一参数类型：应用层传字符串就全用
String，数据库字段是VARCHAR就别用数字型占位符 - 在WHERE里显式CAST反而危险（如
WHERE CAST(phone AS CHAR) = ?），直接破坏索引；正确做法是改应用传参，或加函数索引（MySQL 8.0+支持CREATE INDEX idx_phone ON users ((CAST(phone AS CHAR)))）
高频UPDATE真正难的从来不是语法，而是索引设计与事务边界的拿捏——一个没覆盖的WHERE条件、一次没意识到的隐式转换、一行没加锁的余额校验，都可能在线上放大成雪崩。别迷信“单条SQL更原子”，有时候分两步（SELECT FOR UPDATE + UPDATE）反而更可控、更可测。
