真正有效的解法是分段+批量+显式事务控制：sql server用top+主键推进并建复合索引；oracle用bulk collect+limit+forall；mysql用变量游标模拟分批并加for update；所有场景均需每批显式事务、错误处理及合理批次大小（推荐2000起调优）。
直接用单事务处理百万级以上数据，基本等于让数据库“窒息”——锁升级、日志爆满、超时断连、SSMS卡死是常态。真正有效的解法不是调优单条语句，而是把大操作切成可控小块：分段 + 批量 + 显式事务控制。
SQL Server 用 TOP + 主键推进，别碰 OFFSET/FETCH
OFFSET/FETCH 每次都要跳过前 N 行，10 万行后性能断崖下跌；TOP + 主键推进才是稳定做法。
- 起始点必须动态查：
DECLARE @min_id BIGINT = (SELECT MIN(id) FROM orders WHERE status = 'pending')，不能硬编码 - 更新语句必须带
ORDER BY id，否则TOP (5000)行为不可预测 - 每次更新后立即刷新起点：
SELECT @min_id = MIN(id) FROM orders WHERE status = 'pending' AND id > @min_id - 加
IF @@ROWCOUNT = 0 BREAK，防止空结果集导致无限循环 -
status和id必须建复合索引，否则每次WHERE都全表扫描
Oracle 19c 必须用 BULK COLLECT + LIMIT，别写 WHILE 循环
传统 WHILE + SELECT INTO 在百万级下必然失败：全量加载撑爆 PGA、回滚段暴涨、每批都全表排序。
-
LIMIT推荐值固定为100～500，19c 实测LIMIT 500吞吐与内存占用最平衡 - 必须搭配
FORALL使用，否则只是“伪批量”，上下文切换开销照旧 - 每次
FETCH后检查v_batch.COUNT = 0再退出，不能只靠%NOTFOUND - 游标里加
/*+ INDEX(a idx_status_time) */强制走索引，WHERE 条件字段不能包函数（如TRUNC(create_time)） - 每批处理完要 COMMIT，但别无条件 commit——建议每 1000 行一次，避免 I/O 过载
MySQL 用变量游标模拟分批，绕过 UPDATE + LIMIT 限制
MySQL 不允许 UPDATE ... LIMIT 直接关联源表，但可用变量构造逻辑游标。
- 每次执行前必须重置变量：
SET @row_index := -1，否则第二次运行会漏数据 - 子查询里
ORDER BY id不可省，否则@row_index分配顺序不保证 - 典型写法：
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) - 并发场景下可能漏行或重复，建议加
SELECT ... FOR UPDATE预占，或由应用层用分布式锁协调 -
WHERE条件字段必须有索引，且不能是表达式，否则ORDER BY会触发 filesort
所有数据库都绕不开的事务与错误陷阱
分批不等于安全。没加事务控制或错误处理，失败时根本不知道卡在哪一批。
- 每批必须显式
BEGIN TRANSACTION→ 执行 →COMMIT或ROLLBACK，不能依赖自动提交 - SQL Server 必须包在
TRY...CATCH块里，捕获死锁（错误1205）后记录并重试 - MySQL 存储过程中，
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION是刚需，否则异常直接中断流程 - 批次大小不是越小越稳：
500行太碎，事务开销反升；10000行又容易触发锁等待超时——推荐从2000起调优 - 别忽略自治事务：日志记录要用
PRAGMA AUTONOMOUS_TRANSACTION，否则主事务一回滚，日志也消失
真正难的不是写对第一批，而是保证第 100 批还能正确续跑、出错能定位、并发不串行、日志不丢——这些细节没兜住，再漂亮的分批逻辑也会在线上崩出意料之外的问题。
