分批更新是优化大表更新的最稳妥手段，需基于自增主键或时间戳等有序字段，用WHERE BETWEEN+LIMIT分片，每批独立事务并提交后执行下一批，配合监控与回滚验证。

大表更新慢，核心问题是单次操作扫描和锁定了太多数据。分批更新能显著降低锁竞争、减少事务日志压力、避免超时和内存溢出，是生产环境最稳妥的优化手段。

明确分批依据：优先用主键或有序索引列

分批必须基于可排序、无空缺、高选择性的字段，最常用的是自增主键（如 id）或时间戳字段（如 create_time）。避免用无序字段（如随机UUID、状态码）分片，否则无法保证每次取到稳定的数据块，还可能漏更或重复更新。

• 查出全表最小和最大 id：SELECT MIN(id), MAX(id) FROM orders;
• 设定每批处理 5000 条：SET @batch_size = 5000;
• 用 WHERE id BETWEEN ? AND ? 控制范围，配合 ORDER BY id 确保顺序

用循环+WHERE条件实现安全分批（MySQL示例）

不依赖存储过程也能实现，关键是每次只更新一个确定区间，并在下次迭代前确认上一批已提交。

• 起始点从最小 id 开始，每次加 batch_size 得到下一批上限
• 更新语句带 LIMIT 防止误操作：UPDATE orders SET status = 'done' WHERE id BETWEEN 10001 AND 15000 LIMIT 5000;
• 检查 ROW_COUNT() 是否为 0，为 0 则说明已处理完，退出循环
• 每批后加短暂停（如 SLEEP(0.1)），缓解主库压力，也便于监控中断

注意事务与日志影响

即使分批，每批仍是一个独立事务。若单批耗时仍长（如 >30 秒），需进一步缩小 batch_size；若日志暴涨，可考虑临时调整 innodb_log_file_size 或启用 binlog_row_image=MINIMAL（MySQL 5.6+）。

• 禁止在事务中跨多批——每批必须 COMMIT 后再启下一批
• 避免在高并发写入表上同时跑大批量 UPDATE，尽量选业务低峰期
• 提前在从库验证语句执行计划，确保走的是主键索引，而非全表扫描

上线前必做三件事

分批更新不是“写了就跑”，必须验证闭环。

• 先在测试库用相同数据量压测，记录单批平均耗时和总耗时
• 写回滚脚本（例如按 update_time 和旧值还原），并验证可用性
• 加监控：每批执行后记录 start_id、end_id、影响行数、耗时，便于异常定位