大DELETE易卡死因锁升级、日志暴涨、阻塞严重；应分批删除（如TOP @BatchSize循环）、调简恢复模式、用分区表交换，而非调内存或加索引。
SQL Server 2022 中大事务 DELETE 性能差，核心问题不是语法写错，而是默认行为会锁住所有待删行、产生海量日志、触发锁升级，并可能阻塞其他查询。优化关键在于「控制规模」「减少锁粒度」「规避日志爆炸」，而不是调大内存或加索引。
为什么大 DELETE 容易卡死或失败
直接 DELETE FROM Orders WHERE OrderDate 删除百万行时，SQL Server 2022（不含优化锁定）会：
- 尝试为每一行加
X行锁，直到事务结束 —— 锁内存飙升，容易触发锁升级到页锁甚至表锁 - 每删一行都记完整日志（即使简单条件），
tempdb和事务日志文件快速膨胀 - 阻塞所有读操作（除非开启
READ_COMMITTED_SNAPSHOT），下游报表或 API 可能超时 - 若中途失败，回滚代价极高 —— 日志重做量 ≈ 删除量
用 TOP + 循环分批删，但别手写 WHILE
手动 WHILE + DELETE TOP (10000) 虽可行，但容易写出无限循环或漏删（比如 WHERE 条件在循环中未动态更新）。更稳妥的是用 OFFSET / FETCH 或基于主键的游标式推进：
DECLARE @BatchSize INT = 5000;
WHILE @@ROWCOUNT > 0
BEGIN
DELETE TOP (@BatchSize) FROM Orders
WHERE OrderDate < '2020-01-01'
AND OrderID IN (
SELECT TOP (@BatchSize) OrderID
FROM Orders
WHERE OrderDate < '2020-01-01'
ORDER BY OrderID
);
END;- 必须带
ORDER BY OrderID确保每次删的是新一批，避免重复或跳过 - 不要用
NOT IN或子查询无索引字段，否则每次扫描全表 - 批次大小选 1000–10000：太小 → 开销集中在循环控制；太大 → 单次锁/日志压力仍高
用分区切换（Partition Switch）替代 DELETE
如果目标数据天然按时间分区（如每月一个分区），SWITCH 是秒级清空的唯一真解：
- 前提是表已建好分区函数和方案，且待删数据全部落在某个独立分区上
-
ALTER TABLE Orders SWITCH PARTITION 3 TO Orders_Archive;不记日志、不锁表、不产锁争用 - 后续只需
DROP TABLE Orders_Archive，比任何DELETE快两个数量级 - SQL Server 2022 完全支持该操作，无需额外配置
禁用非必要索引和约束（仅限维护窗口）
大删前临时禁用非聚集索引，能显著减少日志量和 CPU 消耗：
ALTER INDEX IX_Orders_CustomerID ON Orders DISABLE; -- 执行分批 DELETE ALTER INDEX IX_Orders_CustomerID ON Orders REBUILD;
- 只禁用非聚集索引（
DISABLE），聚集索引（主键）不能禁用 - 外键约束若非强依赖，可先
NOCHECK CONSTRAINT，删完再CHECK验证 - 此操作需独占表权限，务必在低峰期执行，并记录操作日志
真正影响性能的从来不是那条 DELETE 语句本身，而是它运行时所处的上下文：是否锁表、是否写爆日志、是否让其他业务等得不耐烦。分批、分区、禁索引这三招，本质都是在把“一个巨石”拆成“一堆小沙”，让 SQL Server 的引擎能喘得上气。别迷信“加内存”或“换 SSD”，先看锁和日志——它们才是 2022 里最沉默的瓶颈。
