row_number()必须带order by，否则在postgresql、sql server、mysql 8.0+中均报错；需用唯一稳定字段（如id或created_at）排序，避免order by 1或rand()，且where不可直接引用rn，须用cte或子查询封装后过滤。
ROW_NUMBER() 必须带 ORDER BY，否则直接报错
不写 ORDER BY 的 ROW_NUMBER() 在 PostgreSQL、SQL Server、MySQL 8.0+ 全部非法。错误信息类似 window function requires an ORDER BY clause。这不是可选项，是 SQL 标准强制要求——窗口函数必须有明确排序依据，否则数据库无法决定“第 1 行”是谁。
常见误区是用 ORDER BY (SELECT NULL) 或 ORDER BY 1 试图“保持原顺序”，但这是无效的：ORDER BY 1 只表示按第一列升序，若该列值重复或含 NULL，编号顺序仍不可控；而 SELECT NULL 在多数引擎中甚至不被允许。
- ✅ 正确兜底写法：用主键或唯一时间戳，如
ORDER BY id或ORDER BY created_at, id - ⚠️ 避免
ORDER BY RAND()：每次执行结果不同，且全表扫描开销极大 - ⚠️ 不要依赖物理插入顺序：SQL 不保证未显式排序时的行序，即使当前看着“顺”，下次就可能变
ORDER BY 字段重复时，ROW_NUMBER() 编号不稳定
当 ORDER BY 列存在重复值（比如多个 created_at = '2026-09-01 10:00:00'），数据库对这些行的相对编号顺序不作保证。同一查询反复执行，rn = 1 可能落在不同行上——这不是 bug，是标准允许的未定义行为。
快速检查是否踩坑：SELECT COUNT(*) FROM t GROUP BY created_at HAVING COUNT(*) > 1，看是否有高重复度字段。
- ✅ 稳定写法：补一个决胜字段，最可靠的是主键，如
ORDER BY created_at DESC, id DESC - ✅ 处理 NULL：用
COALESCE(created_at, '1970-01-01')统一 NULL 排序位置 - ⚠️ 慎用毫秒级时间戳：高并发下事务提交顺序、时钟漂移仍可能导致撞车
PARTITION BY 后 rn = 1 不代表全局唯一
写了 PARTITION BY user_id，每个用户组内都会有一个 rn = 1。如果你在 WHERE rn = 1 前没套子查询或 CTE，还误以为这是“全表只留一条”，就会漏数据或逻辑错乱。
典型反例：SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn FROM t WHERE rn = 1 —— 这条语句根本跑不通，因为 WHERE 执行早于窗口计算。
- ✅ 正确结构：必须用 CTE 或子查询包裹，再在外层筛选，如
WITH ranked AS (...) SELECT * FROM ranked WHERE rn = 1 - ✅ 检查分组基数：
SELECT COUNT(DISTINCT user_id), COUNT(*) FROM t，若两者接近，说明PARTITION BY实际失效 - ⚠️ NULL 值分组风险：所有
user_id IS NULL的行会被归为同一组，可能意外聚合无关数据
WHERE 中不能直接引用 rn 别名
rn 是窗口函数生成的别名，它在 SQL 执行顺序中属于“窗口计算阶段”，晚于 WHERE 和 GROUP BY，早于 ORDER BY。所以 WHERE rn = 1 一定会报 Unknown column 'rn' 或语法拒绝。
这个限制和数据库版本无关，是 SQL 标准执行模型决定的。哪怕你加了 ORDER BY，也改不了这个顺序。
- ✅ 唯二可行方案：子查询嵌套（
SELECT * FROM (SELECT ..., ROW_NUMBER() ... AS rn) t WHERE t.rn = 1）或 CTE（WITH t AS (...) SELECT * FROM t WHERE rn = 1） - ✅ 别名避开保留字：别用
rank、row_number作别名，某些方言（如 Hive）会解析冲突 - ⚠️ 性能提示：CTE 在 PostgreSQL/SQL Server 中通常比多层子查询更易优化，但 MySQL 8.0 对 CTE 支持有限，需实测执行计划
真正容易被忽略的点在于：你以为加了 id 就万事大吉，却没检查 id 是否可能为 NULL，或者 PARTITION BY 字段本身大量为 NULL——这时所有 NULL 行被塞进同一组，编号逻辑已脱离业务预期。
