SQL Server 不允许 DELETE TOP(N) 配合 ORDER BY，因 TOP 仅按物理顺序取行；可靠方案是用 CTE + ROW_NUMBER() 排序编号后删除，需用 created_at DESC, id DESC 确保唯一性，禁用 RANK 等非连续编号函数。
为什么不能直接用 DELETE TOP(N) 配合 ORDER BY？
SQL Server 不允许在 DELETE 语句中直接使用 ORDER BY，哪怕你写了 DELETE TOP(5) FROM t ORDER BY created_at DESC，也会报错：Incorrect syntax near the keyword 'ORDER'。这不是语法疏漏，而是引擎设计限制——TOP 在 DELETE 中只按物理存储顺序取行，不保证逻辑排序结果。
用 CTE + ROW_NUMBER() 实现可控的 TOP N 删除
最可靠、兼容性最好的方式是把排序+编号逻辑提前到 CTE 中，再对编号做条件删除。关键点在于：必须用可唯一排序的字段（如时间戳+主键）避免重复行被误删或漏删。
- 如果
created_at可能重复，务必加上id或其他唯一列补全排序：ORDER BY created_at DESC, id DESC -
ROW_NUMBER()是必需的，RANK()或DENSE_RANK()会导致编号跳空或重复，破坏WHERE rn 的精确性 - CTE 必须包含所有参与排序的列，且不能省略
FROM表的别名（否则部分版本报错）
WITH ranked AS (
SELECT id, created_at,
ROW_NUMBER() OVER (ORDER BY created_at DESC, id DESC) AS rn
FROM orders
)
DELETE FROM ranked WHERE rn <= 10;
用临时表替代 CTE 的适用场景
当目标表极大、CTE 执行计划不稳定，或需多次复用排序结果时，显式建临时表更可控。注意：临时表必须带主键或唯一索引，否则 DELETE 可能影响意外行数。
- 临时表名用
#temp而非##temp，避免跨会话干扰 -
SELECT INTO #temp会自动创建列结构，但不会继承原表索引，后续DELETE性能可能下降 - 执行完立即
DROP TABLE #temp，防止锁残留或 tempdb 膨胀
SELECT TOP(10) id INTO #top_ids FROM orders ORDER BY created_at DESC, id DESC; DELETE o FROM orders o INNER JOIN #top_ids t ON o.id = t.id; DROP TABLE #top_ids;
事务与锁行为容易被忽略的细节
这类操作默认以行锁执行，但如果排序字段无索引，SQL Server 可能升级为页锁甚至表锁，阻塞并发写入。更隐蔽的问题是：CTE 方式在 DELETE 时仍会扫描全表生成 ROW_NUMBER()，即使只删 10 行。
- 确保
ORDER BY字段有索引，例如CREATE INDEX IX_orders_created_id ON orders(created_at DESC, id DESC) - 大表操作前加
SET LOCK_TIMEOUT 5000，避免长时间锁等待导致超时 - 如果业务允许，优先考虑
DELETE ... OUTPUT记录被删 ID，便于事后核对或回滚
真正麻烦的不是写法，而是排序依据是否稳定、索引是否存在、以及锁范围是否被低估。删之前先 SELECT TOP(10) ... ORDER BY 看结果，比直接跑 DELETE 安全得多。
