row_number()必须在子查询或cte中使用，因窗口函数执行晚于where；partition by需按业务分组，order by须含时序字段并补唯一键防重复。
直接用 ROW_NUMBER() 配合子查询或 CTE 是 SQL Server 里最可靠、最通用的做法，没有例外场景能绕过这个结构。
为什么不能在 WHERE 里直接写 ROW_NUMBER()？
因为窗口函数的执行时机晚于 WHERE。SQL Server 的执行顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。而 ROW_NUMBER() 属于 SELECT 阶段计算的内容，WHERE 根本“看不见”它。
常见错误现象：
-
WHERE ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) = 1→ 直接报错：Invalid usage of the window function 'ROW_NUMBER' in the 'WHERE' clause - 把
ROW_NUMBER()放在 GROUP BY 后面尝试聚合 → 语法不通过，窗口函数和聚合不能混在同一层级
PARTITION BY 和 ORDER BY 怎么配才对？
分组字段必须对应业务语义上的“一组”，排序字段必须带明确时序或版本含义；否则“最新”就是无意义的。
-
PARTITION BY user_id：每个用户独立编号，不是按id或order_id -
ORDER BY updated_at DESC：时间倒序，确保最新排第一；用ASC就变成取最早一条 - 如果
updated_at可能重复（比如批量导入、毫秒级精度缺失），务必追加唯一字段防并列：ORDER BY updated_at DESC, id DESC - 避免用
ORDER BY name ASC这类无时序字段——它无法定义“最新”，结果不可控
子查询 vs CTE：选哪个更稳？
两者性能基本一致，但可读性和调试成本差异明显。
- 子查询适合单次简单过滤：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY price DESC) AS rn FROM products) t WHERE t.rn = 1 - CTE 更推荐用于多步逻辑或需复用中间结果的场景，比如先排名、再关联用户表、最后筛选：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (PARTITION BY device_id ORDER BY report_time DESC) AS rn FROM logs) - CTE 在 SQL Server 中支持递归，也更容易加注释、拆解调试；子查询嵌套过深时容易漏括号或别名冲突
真正容易被忽略的是排序稳定性：只要 ORDER BY 字段存在重复值且未补充唯一键，ROW_NUMBER() 每次执行都可能返回不同行——这在定时任务或报表生成中会导致数据漂移，必须主动防御。
