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 就成了黑盒，后续排查就只剩翻备份了。
