优化UPDATE语句首要确保WHERE条件走有效索引，避免全表扫描和长锁等待；需用EXPLAIN验证执行计划，复合索引遵循最左前缀原则，禁用函数操作或隐式转换。
优化 MySQL 的 UPDATE 语句，核心是减少锁等待、降低 I/O 开销、避免全表扫描，并让执行计划尽可能走索引。关键不在于语句写得多“炫”，而在于数据结构
确保 WHERE 条件走有效索引
这是影响 UPDATE 性能的首要因素。如果 WHERE 子句无法命中索引，MySQL 就得扫描全表（或大量行），不仅慢，还会加更长时间的行锁或间隙锁，阻塞其他事务。
- 用
EXPLAIN UPDATE ...（或改写为等价的SELECT）确认执行计划是否用了索引，type至少是ref或更好，key显示实际使用的索引名 - 复合索引要注意最左前缀原则。例如
WHERE status = 'pending' AND created_at > '2025-01-01'，适合建(status, created_at)而非(created_at, status) - 避免在 WHERE 字段上做函数操作或隐式类型转换，比如
WHERE DATE(update_time) = '2025-05-01'会失效索引；应改用范围查询：WHERE update_time >= '2025-05-01' AND update_time
控制单次更新的数据量
一次性更新几百万行，容易导致事务过大、undo 日志膨胀、主从延迟、锁升级（如行锁升级为表锁），甚至触发 OOM 或超时中断。
- 拆成小批量更新，例如每次 1000–5000 行，用主键或自增 ID 分页：
UPDATE t SET status = 2 WHERE id BETWEEN 10001 AND 11000 AND status = 1 - 配合
SLEEP(0.01)（在应用层控制节奏）或使用ROW_COUNT()判断是否还有数据可更新，避免空跑 - 对大表做批量更新前，建议先在从库或测试环境验证耗时和锁表现
减少更新列的数量与长度
更新字段越多、值越长（尤其 TEXT / BLOB），产生的 redo log、binlog 和 buffer pool 压力越大；若字段本身没变，还可能触发无谓的磁盘写入。
- 只 SET 真正需要变更的列，不要写
SET col1 = col1, col2 = 'new'这类冗余赋值 - 避免更新主键或被频繁用作二级索引前导列的字段（如
UPDATE ... SET user_id = ?），这可能导致索引树分裂和大量二级索引更新 - 对大字段更新要格外谨慎，可考虑先查后判：应用层先
SELECT id, large_col，确认值不同再发 UPDATE，避免无效写入
注意事务隔离级别与锁行为
不同隔离级别下，UPDATE 的加锁逻辑差异很大。高并发场景下，错误的隔离级别或 WHERE 条件可能引发死锁或长等待。
- 默认的
REPEATABLE READ下，UPDATE 会加 next-key lock（记录 + 间隙锁），防止幻读但也容易锁住更大范围；若业务允许，可临时调低到READ COMMITTED减少间隙锁 - 用
SELECT ... FOR UPDATE预加锁时，务必保证和后续 UPDATE 的 WHERE 条件完全一致，否则可能锁错行或漏锁 - 监控
SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK，分析死锁日志，重点看两个事务各自持有哪些锁、等待什么锁
