优化UPDATE语句首要确保WHERE条件走有效索引，避免全表扫描和长锁等待；需用EXPLAIN验证执行计划，复合索引遵循最左前缀原则，禁用函数操作或隐式转换。
优化 MySQL 的 UPDATE 语句，核心是减少锁等待、降低 I/O 开销、避免全表扫描，并让执行计划尽可能走索引。关键不在于语句写得多“炫”，而在于数据结构、索引设计和更新方式是否匹配实际场景。
确保 WHERE 条件走有效索引
这是影响 UPDATE 性能的首要因素。如果 WHERE 子句无法命中索引，MySQL 就得扫描全表（或大量行），不仅慢，还会加更长时间的行锁或间隙锁，阻塞其他事务。
- 用
EXPLAIN UPDATE ...（或改写为等价的SELECT）确认执行计划是否用了索引，type至少是ref或更好，key显示实际使用的索引名 - 复合索引要注意最左前缀原则。例如
WHERE status = 'pending' AND created_at > '2024-01-01'，适合建(status, created_at)而非(created_at, status) - 避免在 WHERE 字段上做函数操作或隐式类型转换，比如
WHERE DATE(update_time) = '2024-05-01'会失效索引；应改用范围查询：WHERE update_time >= '2024-05-01' AND update_time
控制单次更新的数据量
一次性更新几百万行，容易导致事务过大、undo 日志膨胀、主从延迟、锁升级（如行锁升级为表锁），甚至触发 OOM 或超时中断。
iWebShop开源商城系统
下载
iWebShop是一款基于PHP语言及MYSQL数据库开发的B2B2C多用户开源免费的商城系统，系统支持自营和多商家入驻、集成微信商城、手机商城、移动端APP商城、三级分销、视频电商直播、微信小程序等于一体，它可以承载大数据量且性能优良，还可以跨平台，界面美观功能丰富是电商建站首选源码。iWebShop开源商城系统 v5.14 更新日志：新增商品编辑页面规格图片上传优化商品详情页面规格图片与主图切
- 拆成小批量更新，例如每次 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，分析死锁日志，重点看两个事务各自持有哪些锁、等待什么锁
