应使用ROW_NUMBER()配合CTE或子查询实现分组删除，因其严格保序无重复，可精准控制前N行；RANK()和DENSE_RANK()因并列排名会导致删除行数不可控。
用 ROW_NUMBER() 标记分组内行号再过滤
窗口函数本身不能直接用于 DELETE 语句（MySQL 8.0+、PostgreSQL、SQL Server 等均不支持在 DELETE 中嵌套窗口函数），必须借助子查询或 CTE 把排名结果“固化”出来。最稳妥的做法是先用 ROW_NUMBER() 按分组和排序规则打标，再在外层删掉排名 ≤ N 的行。
常见错误是误用 RANK() 或 DENSE_RANK()：它们对相同排序值会给出相同排名，导致实际删除行数不可控；而 ROW_NUMBER() 严格保序、无重复，能精准控制“前 N 行”。
示例（删除每个 category 下销量最高的 2 条记录）：
WITH ranked AS (
SELECT id, category, sales,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn
FROM products
)
DELETE FROM products
WHERE id IN (SELECT id FROM ranked WHERE rn <= 2);
注意：id 必须是唯一标识列，否则子查询可能匹配到多条或漏删；若无自然主键，需确保 SELECT 子句中包含足够去重的字段组合。
MySQL 8.0+ 中避免临时表报错的关键写法
MySQL 对“同一语句中修改并读取目标表”限制极严，上面的 DELETE ... WHERE id IN (SELECT ...) 在某些版本会报错 You can't specify target table 'products' for update in FROM clause。此时必须用派生表绕过限制：
- 把内层查询再包一层
SELECT *，让 MySQL 认为它是临时结果集 - 不能依赖别名直接关联，CTE 在 MySQL 8.0+ 虽支持，但 DELETE + CTE 仍受限，优先选派生表
修正写法：
DELETE FROM products
WHERE id IN (
SELECT id FROM (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn
FROM products
) AS tmp
WHERE rn <= 2
);
PostgreSQL 和 SQL Server 可直接用 CTE + DELETE
PostgreSQL 支持 DELETE ... USING，SQL Server 支持 DELETE FROM cte，两者都能更干净地表达意图，且性能通常更好（避免多次扫描）。
PostgreSQL 示例（推荐）：
WITH ranked AS (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn
FROM products
)
DELETE FROM products
USING ranked
WHERE products.id = ranked.id AND ranked.rn <= 2;
SQL Server 示例：
WITH ranked AS (
SELECT id,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn
FROM products
)
DELETE FROM ranked WHERE rn <= 2;
注意：SQL Server 这里删的是 CTE 引用的基表行，不是 CTE 本身；但要求 CTE 必须可更新（即只引用单表、无聚合/去重等）。
ORDER BY 中 NULL 值处理常被忽略
如果排序字段（如 sales）含 NULL，不同数据库默认行为不同：PostgreSQL 默认 NULLS LAST，MySQL 和 SQL Server 默认把 NULL 当最小值。这会导致 “Top N” 结果意外包含 NULL 行。
显式声明更安全：
- 想排除
NULL：加WHERE sales IS NOT NULL预过滤 - 想控制
NULL排序位置：PostgreSQL 用ORDER BY sales DESC NULLS LAST；SQL Server / MySQL 可用ORDER BY CASE WHEN sales IS NULL THEN 1 ELSE 0 END, sales DESC
没处理好 NULL，Top N 就可能删错数据——尤其是业务上 NULL 代表“未录入”而非“零销量”时，后果很直接。
