应采用键集分页替代 OFFSET-FETCH：以主键或唯一递增字段为游标，配合复合索引（如 IX_logs_created），避免函数排序和 NOT IN 子查询，确保高效稳定。
SQL Server 存储过程中怎么写分页批处理
直接用 OFFSET-FETCH 做分页在大数据量下会越来越慢，尤其当 OFFSET 超过百万行时，SQL Server 仍要扫描前面所有行。更稳的做法是用「键集分页（Keyset Pagination）」：靠主键或唯一递增字段（如 id）做游标，每次只查下一批。
实操建议：
- 确保分页字段有索引——比如
CREATE INDEX IX_logs_created ON logs(created_at, id)，复合索引顺序影响性能 - 避免
ORDER BY NEWID()或函数表达式排序，会导致无法走索引 - 不要用
TOP @batchSize+NOT IN (SELECT ……)，数据量大时子查询变全表扫描 - 示例逻辑：
DECLARE @lastId INT = 0;<br>WHILE @lastId IS NOT NULL<br>BEGIN<br> SELECT TOP 1000 id, content FROM logs <br> WHERE id > @lastId ORDER BY id;<br> IF @@ROWCOUNT = 0 BREAK;<br> SELECT @lastId = MAX(id) FROM (SELECT TOP 1000 id FROM logs WHERE id > @lastId ORDER BY id) t;<br>END
MySQL 存储过程里怎么安全地批量更新百万行
直接 UPDATE big_table SET status = 1 WHERE condition 容易锁表、占满 binlog、触发超时。必须拆成小事务 + 显式控制提交节奏。
关键点：
- 用
WHERE id BETWEEN ? AND ?切片，别依赖LIMIT配合ORDER BY，否则可能漏行或重复 - 每次更新后加
DO SLEEP(0.1)（MySQL 5.7+），缓解主从延迟和 I/O 压力 - 务必检查
innodb_buffer_pool_size是否足够，否则频繁刷脏页反而拖慢 - 错误现象：执行中报
Lock wait timeout exceeded，说明事务太久或锁冲突，这时应缩小批次（如从 5000 改为 1000）
PostgreSQL 中用游标分批处理为什么比 LIMIT 更可靠
因为 DECLARE c CURSOR FOR …… 是服务端游标，不把全部结果集拉到客户端内存，且支持 FETCH FORWARD 1000 精确取数，不受并发 DML 导致的 LIMIT OFFSET 错位影响。
注意这些细节：
- 游标默认是
NO SCROLL，不能倒退，适合单向处理场景 - 在存储过程中用
MOVE FORWARD 1000 IN c比FETCH 1000 FROM c更轻量（不返回数据） - 如果业务允许，优先用
READ ONLY游标，避免事务膨胀 - 别忘了显式
CLOSE c，否则长期运行可能耗尽游标句柄（max_cursor有限制）
跨数据库通用的批处理防坑要点
不是所有数据库都支持变量绑定游标或动态 FETCH 数量，真正容易被忽略的是「状态一致性」——比如某批成功、下一批失败，中间状态怎么回滚或续跑。
实操底线：
- 每批操作前记录起点（如
last_processed_id到一张控制表），失败时可重试而非重头来 - 避免在循环里反复查同一张大表的统计值（如
COUNT(*)），改用预估行数或采样 - Oracle 的
BULK COLLECT LIMIT和 SQL Server 的TABLESAMPLE不是等价替代，前者是 PL/SQL 内存控制，后者是抽样，别混用 - 日志一定要打在批处理边界上，例如「[BATCH] processed rows 10000–10999」，不然出问题根本没法定位哪一环断的
