MySQL存储过程中用WHILE+LIMIT分批更新或删除需以主键推进、每批独立COMMIT、用ROW_COUNT()判断退出，避免OFFSET导致性能断崖，且WHERE字段必须有复合索引。
MySQL存储过程里用WHILE+LIMIT分批更新或删除
直接写 UPDATE table SET ... WHERE condition 处理百万行，大概率触发锁升级、日志爆满、连接超时。必须切批次，且每批独立事务。
-
LIMIT后可接变量（MySQL 5.7+），但别依赖OFFSET：越往后扫描越慢，10万行后性能断崖下跌 - 用主键推进更稳：
WHERE id > @last_id AND status = 'pending' ORDER BY id LIMIT 5000，每次删完立刻SELECT MAX(id)更新@last_id - 必须在循环内显式
COMMIT，否则整个WHILE被包在一个事务里，undo log不释放，磁盘撑爆 - 加
ROW_COUNT()判断退出：SELECT ROW_COUNT() INTO @affected，等于 0 就LEAVE，别硬设循环次数 - WHERE 条件字段没索引？先加：
ALTER TABLE orders ADD INDEX idx_status_id (status, id)，否则每次LIMIT前都全表扫
SQL Server用TOP+主键推进避免全表扫描
OFFSET/FETCH 在大表上根本不能用——它每次都要跳过前 N 行，IO 和 CPU 开销随偏移量线性增长。稳定做法是靠主键或时间戳“游标式”推进。
- 起始点必须查出来：
DECLARE @min_id BIGINT = (SELECT MIN(id) FROM orders WHERE status = 'pending')，不能硬编码 -
UPDATE TOP (2000) orders SET status = 'processed' WHERE id >= @min_id AND status = 'pending' ORDER BY id——ORDER BY缺不得，否则TOP行为无定义 - 更新完立刻刷新游标：
SELECT @min_id = MIN(id) FROM orders WHERE status = 'pending' AND id > @min_id - 加
IF @@ROWCOUNT = 0 BREAK，防止空结果集导致无限循环 - 复合索引
(status, id)是刚需，否则WHERE条件走不了索引，等于白优化
PostgreSQL用DELETE RETURNING安全分批
PG 不支持带 LIMIT 的非事务安全 DELETE，先 SELECT id 再 DELETE WHERE id IN () 有竞态风险——中间被其他事务插入/删除，漏行或误删。
- 用
WITH batch AS (DELETE FROM logs WHERE created_at 一次定位、一次删除、拿到结果继续下一批 - RETURNING 返回的
id必须存下来作为下一批起点，别用ctid——VACUUM 后失效 - 条件字段必须有索引：
CREATE INDEX CONCURRENTLY idx_logs_created ON logs(created_at)，CONCURRENTLY避免锁表 - 批量太大时拆成 1000–5000 行一批，配合
pg_sleep(0.01)降低系统负载
所有数据库都绕不开的事务与错误陷阱
分批不等于健壮。没事务控制、没错误捕获、没重试逻辑，失败时你根本不知道卡在哪一批，更没法续跑。
- 每批必须显式
BEGIN TRANSACTION→ 执行 →COMMIT或ROLLBACK，不能依赖自动提交 - SQL Server 必须套
TRY/CATCH，专门捕获死锁错误（ERROR_NUMBER() = 1205），记录后重试，而不是崩掉整个过程 - MySQL 存储过程中，
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION是刚需，否则异常直接中断流程 - 批次大小不是越小越安全：500 行太碎，事务开销占比反升；10000 行又容易触发锁等待超时；从 2000 起调优最稳妥
- 最容易被忽略的不是怎么切批次，而是每次循环后是否真正释放了锁和日志空间——
COMMIT之后再查INFORMATION_SCHEMA.INNODB_TRX或pg_stat_activity确认事务已清空
