ROW_NUMBER() 配合 PARTITION BY 是按分类取最新记录最稳、最通用的解法：先按 category 分组，再在组内按 created_at DESC、id DESC 排序编号，最后取 rn = 1 的行；窗口函数不可直接用于 WHERE，须用子查询或 CTE。
用 ROW_NUMBER() 配合 PARTITION BY 取每组最新一条
直接结论：想按分类取最新记录，ROW_NUMBER() 是最稳、最通用的解法。它不依赖时间字段是否严格唯一，也不怕同分类下多条记录时间相同。
核心逻辑是先按分类分组（PARTITION BY category），再在组内按时间倒序编号（ORDER BY created_at DESC），最后筛出编号为 1 的行。
- 必须写
ORDER BY子句，否则ROW_NUMBER()报错（MySQL 8.0+、PostgreSQL、SQL Server 都强制要求） - 如果时间字段有重复，
ROW_NUMBER()会强行分配不同序号，结果确定但可能和直觉不符；这时可追加二级排序，比如ORDER BY created_at DESC, id DESC - 别用
RANK()或DENSE_RANK()—— 它们对并列值给相同排名，会导致取到多条“最新”记录，不符合“每组只取一条”的需求
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY created_at DESC, id DESC) AS rn FROM products ) t WHERE rn = 1;WHERE 子句里不能直接用窗口函数
常见错误：写成 SELECT * FROM products WHERE ROW_NUMBER() OVER (……) = 1，直接报错 —— 窗口函数不能出现在 WHERE 或 GROUP BY 中，因为执行顺序上它们晚于这些子句。
- 必须用子查询或 CTE 包一层，让窗口计算先完成，再在外面过滤
- CTE 写法更清晰，但部分老版本 MySQL（
- 别试图在
HAVING里绕——HAVING只作用于聚合结果，和窗口函数无关
created_at 为 NULL 时会被排在最前面
默认 ORDER BY xxx DESC 会把 NULL 当作最大值，导致含 NULL 的记录被标为 rn = 1，实际却不是“最新”。这容易被忽略，尤其当数据清洗不彻底时。
- 显式控制
NULL排序：加NULLS LAST（PostgreSQL、Oracle 支持），或用表达式兜底，如ORDER BY (created_at IS NULL), created_at DESC（MySQL/SQL Server 兼容） - 如果业务上
created_at不该为空，建议建表时加NOT NULL约束，比运行时处理更可靠 - 测试时故意插入一条
created_at = NULL的数据，看是否意外命中“最新”
性能关键：PARTITION BY 字段一定要有索引
窗口函数本身不走索引，但 PARTITION BY + ORDER BY 的组合，本质是按分区键分组后再排序。如果 category 和 created_at 没有联合索引，大表上可能触发文件排序（Using filesort），IO 和 CPU 开销陡增。
- 最优索引是
(category, created_at DESC)，注意顺序不能反 - 如果查询还常带其他过滤条件（比如
status = 'active'），可考虑扩展为(category, status, created_at DESC) - 执行前务必看
EXPLAIN，确认是否用了索引，以及是否出现Using temporary; Using filesort
真正麻烦的不是语法写不对，而是数据量上来后查得慢，还查不出问题在哪——索引这事，上线前就得定好，别等告警了再补。
