SQL批量UPDATE性能差主因是逐行更新、缺索引、事务过大及锁竞争；优化需分批更新（每次几千至几万行）、确保WHERE走索引、避免函数操作和全表扫描，并控制事务大小与锁粒度。

SQL批量UPDATE性能差，核心原因通常是单条语句逐行更新、缺乏索引支撑、事务过大或锁竞争激烈。优化关键在于减少IO、降低锁粒度、避免全表扫描，并合理利用数据库特性。

分批次更新，控制事务大小

一次性更新百万级数据极易引发长事务、锁表、日志暴涨甚至OOM。应按主键或有索引的字段切片，每次更新几千到几万行：

• MySQL示例：UPDATE t SET status = 1 WHERE id BETWEEN 10001 AND 20000 AND status = 0;
• 配合循环脚本或存储过程，每次提交后休眠几十毫秒，缓解系统压力
• 避免使用LIMIT在无ORDER BY时更新（结果不确定），务必带上确定性排序条件

确保WHERE条件走索引

全表扫描是批量UPDATE最常见性能杀手。执行前务必检查执行计划（EXPLAIN）：

• WHERE字段必须有有效索引，复合条件注意最左前缀原则
• 避免在WHERE中对字段做函数操作（如WHERE DATE(create_time) = '2024-01-01'），改用范围查询：create_time >= '2024-01-01' AND create_time
• UPDATE涉及的列若被触发器、外键或生成列依赖，也会拖慢速度，临时禁用（需评估业务影响）

考虑替代方案：INSERT … ON DUPLICATE KEY UPDATE 或 MERGE

当更新依据是唯一键（如主键、业务单号），且数据源来自另一张表或临时表时，批量INSERT+冲突更新往往比UPDATE更快：

• MySQL：INSERT INTO t (id, name, status) SELECT id, name, 1 FROM temp_t ON DUPLICATE KEY UPDATE status = VALUES(status);
• PostgreSQL/Oracle 可用MERGE INTO，减少重复查找开销
• 前提：提前把目标数据写入临时表（带索引），再通过JOIN高效匹配

调整数据库配置与维护

硬件和配置层面也有明显提升空间：

• 增大innodb_log_file_size（MySQL）避免频繁刷日志；调高innodb_buffer_pool_size减少磁盘读
• 更新前关闭自动提交，手动控制COMMIT频率；但单个事务别超5分钟，防锁等待和回滚段膨胀
• 更新完成后及时ANALYZE TABLE，更新统计信息，避免后续查询走错执行计划