批量update慢的核心在于执行方式、索引缺失、大事务及数据分布；应分批（1000–5000行/批）、走主键或唯一索引分段、每批独立提交并加短暂停，且where条件必须命中索引，避免函数导致索引失效。
SQL UPDATE 批量修改慢，核心问题通常不在语句本身，而在执行方式、索引、事务和数据分布。优化的关键是减少锁竞争、降低日志压力、避免全表扫描，并让数据库能高效定位目标行。
分批次更新，控制事务大小
单次更新百万行会引发长事务、大量 undo/redo 日志、锁表风险高，极易阻塞其他操作。应拆成小批量（如 1000–5000 行/批），每批独立提交：
- 用主键或唯一索引字段分段，例如：WHERE id BETWEEN 10001 AND 15000
- 循环执行时，用上次最大 ID 作为下一批起点，避免漏更或重复
- 每批后加短暂停（如 10–100ms），缓解 I/O 和锁压力，尤其在生产环境
确保 WHERE 条件走索引
没有有效索引的 UPDATE 实际是全表扫描+逐行判断，性能随数据量陡增。检查执行计划（EXPLAIN）确认是否命中索引：
- WHERE 中的字段必须有合适索引，复合条件优先建联合索引（顺序按等值→范围列排列）
- 避免在索引列上使用函数或表达式，如 WHERE YEAR(create_time) = 2024 无法走索引，改用 create_time >= '2024-01-01' AND create_time
- 字符串比较注意隐式类型转换，如 WHERE mobile = 13812345678 可能导致索引失效（mobile 是 VARCHAR）
减少更新列数与值变更判断
UPDATE 每一行都会写入新版本（即使值未变），触发日志、缓冲区刷新和可能的索引更新。可提前过滤无意义更新：
- 加上值变更条件，例如：SET status = 2 WHERE status != 2 AND …
- 只更新真正需要改的字段，避免 SET col1=col1, col2=?, col3=?（冗余赋值增加开销）
- 对大字段（TEXT/BLOB）单独处理，非必要不参与批量更新
临时关闭非关键约束与日志选项（谨慎使用）
仅适用于维护窗口期、可接受短暂风险的场景：
- MySQL：考虑设置 SET SESSION innodb_flush_log_at_trx_commit = 2（牺牲极小持久性换性能）
- PostgreSQL：可临时设 synchronous_commit = off，但需评估崩溃丢失风险
- 外键或唯一约束检查耗资源，若确定数据合规，可临时禁用（操作完立即恢复）
- 不建议关闭 autocommit 或强行 drop 索引——收益有限，风险极高
真正高效的批量更新，靠的是合理拆分 + 精准定位 + 最小变更。不需要复杂工具，把这几条落实到位，多数场景性能可提升数倍到一个数量级。
