delete top(100) 必须配合 order by 才能可靠删除逻辑上的“前100行”，否则删除任意100行；order by 列需有索引且建议附加唯一列防重复；top 不支持变量，应使用动态sql或offset-fetch；务必先select验证再删除，并在事务中执行。

DELETE TOP(100) 必须配合 ORDER BY 才能可靠删除“前100行”

SQL Server 的 DELETE TOP(100) 本身不保证顺序——它只是随机选 100 行删。所谓“前100行”，必须由 ORDER BY 明确指定排序依据，否则结果不可预测，尤其在有重复值或无聚集索引的表中。

常见错误是写成：DELETE TOP(100) FROM Orders;，这会删掉任意 100 行，不是按时间、ID 或其他逻辑意义上的“前100”。

• 必须写成：DELETE TOP(100) FROM Orders ORDER BY CreatedTime ASC;
• ORDER BY 列最好有索引（尤其是升序），否则排序开销大，还可能触发表扫描
• 如果 CreatedTime 有大量重复值，建议追加主键列保唯一性：ORDER BY CreatedTime ASC, OrderID ASC

TOP 子句不能直接用变量，需用动态 SQL 或 OFFSET-FETCH 替代

想参数化删除前 N 行（比如 N=100 来自变量），DELETE TOP(@n) 会报错：Incorrect syntax near '@n'。TOP 后面只接受字面量或常量表达式，不支持参数。

• 安全做法是用动态 SQL：DECLARE @sql NVARCHAR(MAX) = N'DELETE TOP(' + CAST(@n AS NVARCHAR(10)) + N') FROM Orders ORDER BY OrderID ASC'; EXEC sp_executesql @sql;
• 更推荐 OFFSET-FETCH（SQL Server 2012+）：DELETE FROM Orders WHERE OrderID IN (SELECT OrderID FROM Orders ORDER BY OrderID ASC OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY); ——虽稍慢，但可参数化且语义清晰
• 避免用 ROW_NUMBER() + CTE 做子查询删除，容易因未加 ORDER BY 导致计划不稳定

DELETE TOP 比逐条 DELETE 快，但比 TRUNCATE 危险得多

DELETE TOP 是逐行删除，会记录每行日志、触发触发器、检查外键约束，而 TRUNCATE 是页级操作，快且日志少。但 TRUNCATE 不能带条件、不能回滚到某点、会重置标识列——所以“删前100行”只能用 DELETE。

• 大表慎用：若表有 1000 万行，删前 100 行却要先排序全部数据，性能可能极差；应确保 ORDER BY 列上有高效索引
• 事务日志会增长：即使只删 100 行，日志量也可能远超预期，尤其在完整恢复模式下
• 没加 WHERE 就别手滑写成 DELETE TOP(100) FROM Orders ORDER BY OrderID DESC——这会删最新的 100 行，不是最老的

确认删除范围前，务必先用 SELECT 验证 ORDER BY 结果

执行 DELETE 前，永远先跑等价的 SELECT 查看将被删的是哪些行。别依赖“应该就是前100”这种猜测。

• 正确验证方式：SELECT TOP(100) * FROM Orders ORDER BY OrderID ASC;
• 如果表很大，加 WITH (NOLOCK) 可避免阻塞，但要注意脏读风险：SELECT TOP(100) * FROM Orders WITH (NOLOCK) ORDER BY OrderID ASC;
• 生产环境建议在事务里做预查+删除，防止中间数据变动：BEGIN TRAN; SELECT TOP(100) * FROM Orders ORDER BY OrderID ASC; DELETE TOP(100) FROM Orders ORDER BY OrderID ASC; -- 确认无误再 COMMIT

实际删“前100行”的难点不在语法，而在定义清楚什么叫“前”——是按插入时间？主键？业务状态？这个顺序逻辑一旦模糊，ORDER BY 就成了黑盒，后续排查就只剩翻备份了。