SQL批量更新慢主因是执行计划不合理、锁竞争激烈、日志写入压力大；需分别优化索引与统计信息、分批控制锁粒度、调整日志缓冲与提交策略。
SQL批量更新慢，通常不是因为数据量大本身，而是执行计划不合理、锁竞争激烈、日志写入压力大这三类问题在起作用。优化关键不在“怎么写UPDATE”，而在“数据库怎么执行它”。
执行计划走错路：全表扫描代替索引查找
批量UPDATE若没走预期索引，会触发全表扫描，I/O暴涨，CPU飙升。常见诱因是WHERE条件字段缺失索引、隐式类型转换（比如用字符串匹配INT主键）、或统计信息过期。
- 用red">EXPLAIN或EXECUTION PLAN确认实际是否走了索引；
- 检查WHERE子句字段是否都有合适索引，复合条件注意最左前缀；
- 避免在WHERE中对字段做函数操作（如WHERE YEAR(create_time) = 2024），改用范围查询（create_time BETWEEN '2024-01-01' AND '2024-12-31'）；
- 定期更新统计信息（如SQL Server的UPDATE STATISTICS，MySQL的ANALYZE TABLE）。
锁粒度失控：行锁升级为页锁/表锁
批量更新涉及大量行时，数据库可能自动将多个行锁升级为更大粒度的锁（如SQL Server的锁升级、InnoDB的间隙锁膨胀），导致阻塞加剧、并发下降。
- 控制单次更新行数（例如每次500~5000行），用TOP（SQL Server）或LIMIT（MySQL）分批；
- 确保WHERE条件能精准定位目标行，避免扫描过多无关数据（否则会加更多意向锁和间隙锁）；
- 检查隔离级别，READ COMMITTED以下级别可减少锁持有时间，但需权衡一致性要求；
- 避免在事务中混用UPDATE与SELECT FOR UPDATE等显式锁操作，防止锁范围意外扩大。
日志与IO瓶颈：Redo/Undo日志写满缓冲区
每行更新都要写Redo日志（保障持久性）和Undo日志（支持回滚和MVCC），大批量操作易打爆日志缓冲区，触发频繁刷盘，成为性能瓶颈。
- 增大日志缓冲区（如MySQL的innodb_log_buffer_size，SQL Server的recovery interval相关设置）；
- 批量提交而非单条提交，但也不宜过大——平衡事务大小与崩溃恢复成本；
- 考虑使用INSERT ... ON DUPLICATE KEY UPDATE或MERGE替代多条UPDATE（减少解析开销与日志重复项）；
- 临时关闭非关键约束或索引（仅限维护窗口），更新完成后再重建，可显著降低日志量。
不复杂但容易忽略：一次批量更新的快慢，80%取决于执行路径是否干净、锁是否收敛、日志是否顺畅。盯着语句本身改写不如先看执行计划和锁等待链。
