直接执行大事务会卡死或超时，因其引发锁升级、日志暴涨、内存耗尽；应拆分为每批1k–10k行的小事务，基于主键/时间戳分段更新并显式COMMIT，避免OFFSET/FETCH全表扫描，注意索引、ORDER BY、变量重置及错误处理。
为什么直接执行大事务会卡死或超时
SQL Server 或 MySQL 存储过程中一次性更新/插入几百万行，大概率触发锁升级、日志暴涨、内存耗尽，甚至让整个数据库响应变慢。常见现象包括：Transaction log is full、Timeout expired、SSMS 显示“正在执行”但数小时没反应。
根本原因不是数据量大，而是单事务持有锁时间太长、日志无法及时截断、客户端连接被服务端主动断开。
解决思路很明确：把一个大事务拆成多个小事务，每段控制在 1k–10k 行之间（具体看单行大小和索引复杂度），并显式 COMMIT。
用 TOP + WHERE 实现安全分段（SQL Server）
别用 OFFSET/FETCH 做分页更新——它会在每次执行时全表扫描前 N 行，越往后越慢。更稳的方式是基于有序主键/时间戳推进：
- 先查出最小 ID：
DECLARE @min_id BIGINT = (SELECT MIN(id) FROM orders WHERE status = 'pending') - 循环中每次取一批：
UPDATE TOP (5000) orders SET status = 'processed' WHERE id >= @min_id AND status = 'pending' ORDER BY id - 更新后刷新 @min_id：
SELECT @min_id = MIN(id) FROM orders WHERE status = 'pending' AND id > @min_id - 加
IF @@ROWCOUNT = 0 BREAK防止死循环
注意：必须有 ORDER BY id，否则 TOP 行为不可预测；WHERE 条件字段要建索引，否则每次扫描全表。
MySQL 中用 LIMIT + 变量模拟游标（避免 OFFSET）
MySQL 不支持带 LIMIT 的 UPDATE 直接分页，但可以用变量+子查询实现类似效果：
SET @row_index := -1;
UPDATE orders
SET status = 'processed'
WHERE id IN (
SELECT id FROM (
SELECT id, @row_index := @row_index + 1 AS row_num
FROM orders
WHERE status = 'pending'
ORDER BY id
LIMIT 5000
) AS t
);
这个写法比 UPDATE ... LIMIT 更可控，但要注意：
- 子查询里必须有
ORDER BY，否则@row_index顺序不保证 - 不能在存储过程里反复执行同一语句而不重置变量，否则第二次会从上次结束位置继续
- 如果并发修改源表，可能漏行或重复处理，建议加应用层分布式锁或用
SELECT ... FOR UPDATE预占
批量提交的边界与陷阱
不是“越小越安全”，也不是“越大越快”。5000 行是较通用的起点，但需根据实际调优：
- 事务日志增长：每批提交都会写入 LDF 文件，批次太小会导致日志碎片多、I/O 次数爆炸
- 锁粒度：SQL Server 默认行锁，但超过 5000 行可能升级为页锁或表锁，反而降低并发性
- 网络往返：客户端驱动（如 JDBC/ODBC）对频繁
COMMIT有额外开销，尤其跨机房场景 - 务必在循环内加
WAITFOR DELAY '00:00:00.1'（SQL Server）或SLEEP(0.1)（MySQL），避免 CPU 扛满、抢占系统资源
最常被忽略的是错误处理——某一批失败时，不能简单 ROLLBACK 全局，而应记录失败批次范围，后续人工校验或跳过重试。否则看似“健壮”的脚本，其实悄悄漏掉了最后 3% 的数据。
