DELETE TOP(n) 必须加 ORDER BY 才能可靠删除逻辑上的“前n行”，否则按物理存储顺序随机删n行，结果不可预测；ORDER BY 列需有索引并建议附加唯一列防重复。
SQL Server 里不能直接用 LIMIT，但可以用 TOP (n) 精确控制单次删多少行——前提是必须搭配事务和确定性排序，否则容易漏删、重复删或锁表太久。
为什么 DELETE TOP (n) 必须加 ORDER BY？
因为 TOP 本身不保证顺序，SQL Server 会按物理存储顺序随机取前 n 行。如果没显式指定 ORDER BY，两次执行可能删掉完全不同的数据，尤其在并发写入时更危险。
- 错误写法：
DELETE TOP (1000) FROM logs WHERE created_at —— 不可控 - 正确写法：
DELETE TOP (1000) FROM logs WHERE id IN (SELECT TOP (1000) id FROM logs WHERE created_at - 更稳妥的变体：用 CTE 先锁定有序 ID 集合，再删，避免子查询被重排
怎么防止大删卡死数据库？
单次删太多行会撑爆事务日志、锁住聚集索引、拖慢整个实例。关键不是“一次删多少”，而是“删完立刻提交 + 给系统喘息时间”。
- 每批控制在 5000～10000 行，
TOP值别硬写成 100000 - 每次
DELETE后加WAITFOR DELAY '00:00:00.1'（100ms），让检查点和日志截断有机会运行 - 用
@@ROWCOUNT判断是否继续，而不是查EXISTS(SELECT ...)—— 后者可能触发全表扫描 - 避开业务高峰期；临时关闭
AUTO_UPDATE_STATISTICS，防止删一半统计信息自动更新拖慢速度
事务和锁该怎么配？
不包事务的 TOP 删除看似简单，但出错无法回滚；包太大事务又起反作用。折中方案是每个批次独立事务，并在 WHERE 条件列上确保有索引。
- 必须用
BEGIN TRANSACTION/COMMIT包裹每一批 -
WHERE中的字段（如created_at或status）要有索引，否则TOP子查询会扫全表 - 如果删的是高频更新的表，考虑在子查询里加
WITH (UPDLOCK, READPAST)，跳过已被其他事务锁住的行，避免阻塞 - 别依赖
TABLOCK来“减少日志”——它只是把行锁升级为表锁，日志量未必少，还更容易阻塞读
真正难的不是写出能跑的语句，而是让删的过程可中断、可监控、不伤主库。比如 @@ROWCOUNT == 0 后没及时 BREAK，或者 WAITFOR 时间设太短导致日志持续增长，这些细节比语法本身更容易引发线上事故。
