单事务处理10万行会导致锁资源长期占用、事务日志膨胀、响应延迟及锁升级或超时；必须用WHILE循环+TOP+主键推进+显式事务分批处理，每批500–2000行，配合@last_id追踪和WITH (UPDLOCK, READPAST)等机制保障一致性与可续跑。
为什么不能直接在存储过程中用单个事务处理10万行
大事务会持续占用锁资源、膨胀事务日志、拖慢整体响应，还容易触发SQL Server的锁升级（如从行锁升到表锁）或超时中断。存储过程本身不提供“自动分批”语法，必须靠显式循环+事务控制来模拟。关键不是“能不能”，而是“怎么切得既安全又高效”。
用WHILE循环配合TOP + OFFSET实现可控分页拆分
核心思路是每次只取固定数量（如1000行）待处理数据，在独立事务中执行，避免长事务。注意不能依赖ROW_NUMBER()做全局排序后分页——它在大表上性能差，且无法保证每次取数一致性。
- 优先用主键/索引字段驱动分页，例如：
WHERE id > @last_id ORDER BY id ASC - 避免
OFFSET ... FETCH用于大偏移量（如OFFSET 50000），它仍需扫描前N行 - 每次循环后更新
@last_id为本批最大ID值，确保无遗漏、无重复 - 用
SET XACT_ABORT ON确保语句级失败能回滚整个当前事务
如何防止分批过程中数据被并发修改
如果业务允许“最终一致”，可跳过强一致性控制；但若要求处理期间数据冻结，就得加锁或版本控制。常见做法有：
- 在分批SELECT时加
WITH (UPDLOCK, READPAST)：跳过已被其他事务锁定的行，避免阻塞 - 用
UPDATE TOP (1000) ... OUTPUT一次性取出并标记待处理行（如设status = 'processing'），再逐条处理 - 对目标表加
SCH_M（架构修改）锁虽彻底但影响太大，生产环境慎用
事务嵌套与错误恢复的实际限制
SQL Server不支持真正意义上的“子事务回滚”，SAVE TRANSACTION只能回滚到保存点，无法隔离批次失败。所以更可靠的做法是：
- 每个批次用独立
BEGIN TRAN / COMMIT / ROLLBACK包裹 - 用
TRY...CATCH捕获错误，并记录失败批次范围（如@start_id到@end_id）到日志表 - 不要依赖
@@TRANCOUNT判断外层事务状态——存储过程退出时未提交的事务会自动回滚 - 批量数建议设为500–2000，太小增加调度开销，太大仍可能触发日志增长告警
分批逻辑看似简单，但最容易被忽略的是**状态追踪的可靠性**：没有持久化记录每批起止ID或处理时间戳，就无法安全断点续跑。别指望靠变量或临时表撑过服务器重启。
