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% 取决于执行路径是否干净、锁是否收敛、日志是否顺畅。盯着语句本身改写不如先看执行计划和锁等待链。
