不能直接用 DELETE FROM 表名 WHERE 条件，因为单条语句会锁住所有匹配行、写满事务日志、触发日志文件暴涨甚至填满磁盘；SQL Server 在完整恢复模式下逐行记日志，MySQL 的 innodb_log_file_size 也有硬限制；真正有效的是分批删除+显式事务控制+每批 COMMIT 或 CHECKPOINT。
为什么不能直接用 DELETE FROM 表名 WHERE 条件？
大表删数据时，单条 DELETE 语句会把所有匹配行锁住、写满事务日志，还可能触发日志文件自动增长甚至填满磁盘。SQL Server 默认事务日志是完整恢复模式，每行删除都记日志；MySQL 的 innodb_log_file_size 也有硬限制。游标本身不解决日志问题，关键在“分批 + 显式事务控制”。
真正起作用的是：手动切小事务 + 每批后 CHECKPOINT（SQL Server）或 COMMIT（MySQL/PostgreSQL）+ 控制每批行数。
SQL Server 中用 DECLARE CURSOR + WHILE 分批删的实操要点
游标只是遍历手段，重点在每次只取固定数量主键（避免全表扫描），并在小事务中删除：
- 必须基于有索引的字段（最好是聚集索引主键）做
WHERE过滤，否则游标打开就卡住 - 用
FAST_FORWARD游标类型，它最轻量，不支持反向滚动，但删数据够用 - 每批处理后立刻
COMMIT，并考虑加CHECKPOINT让日志截断（仅适用于简单恢复模式） - 别用
SELECT *声明游标——只选主键列，减少内存占用和锁范围
DECLARE @id INT;
DECLARE batch_cursor CURSOR FAST_FORWARD FOR
SELECT TOP (5000) id FROM orders WHERE status = 'archived' ORDER BY id;
OPEN batch_cursor;
FETCH NEXT FROM batch_cursor INTO @id;
WHILE @@FETCH_STATUS = 0
BEGIN
BEGIN TRANSACTION;
DELETE FROM orders WHERE id = @id AND status = 'archived';
COMMIT;
FETCH NEXT FROM batch_cursor INTO @id;
END;
CLOSE batch_cursor;
DEALLOCATE batch_cursor;
注意：上面是“逐行删”，效率低。生产环境更推荐“按主键范围批量删”，比如每次删 id BETWEEN @start AND @end，再移动窗口。
比游标更稳的替代方案：用 TOP + 循环 DELETE（SQL Server）
游标在 SQL Server 中开销高、易阻塞，且无法并行。实际运维中，90% 场景用以下方式更可靠：
- 用
DELETE TOP (10000)配合WHILE @@ROWCOUNT > 0循环，避免游标初始化开销 - 每次删完加
WAITFOR DELAY '00:00:00.01'（可选），缓解日志压力和锁竞争 - 确保
WHERE条件能走索引，否则TOP仍要扫全表 - 删完立即执行
DBCC SQLPERF(LOGSPACE)观察日志使用率是否回落
WHILE 1=1
BEGIN
DELETE TOP (5000) FROM orders
WHERE status = 'archived';
IF @@ROWCOUNT = 0 BREAK;
WAITFOR DELAY '00:00:00.01';
END;
MySQL 和 PostgreSQL 怎么安全分批删？
它们没游标语法优势，也不鼓励用存储过程模拟游标删大数据——容易锁表或 OOM。直接用应用层或原生分页逻辑更可控：
- MySQL：用
WHERE id > ? ORDER BY id LIMIT 5000，每次记录上一批最大id，下一轮当起点 - PostgreSQL：用
WHERE ctid IN (SELECT ctid FROM 表 WHERE 条件 LIMIT 5000)，避免重复扫描 - 无论哪种，都要在事务外执行，即每批自己
BEGIN; ... COMMIT;，不要包进一个大事务 - 删前确认
autocommit=1（MySQL）或显式COMMIT（PG），否则默认会累积日志
最容易被忽略的一点：删完别忘了更新统计信息（UPDATE STATISTICS 或 ANALYZE TABLE），否则后续查询可能继续走错执行计划，间接拖慢下一批删除。
