窗口函数必须配合order by使用，否则row_number()无法确定“最新”；应优先用shelf_at desc排序，缺则用create_time，避免用id；需在外层where过滤，mysql 5.7以下需用not exists模拟。
窗口函数必须配合 ORDER BY 使用，否则 ROW_NUMBER() 无法确定“最新”
很多人写 ROW_NUMBER() OVER (PARTITION BY category) 就报错或结果不对——因为没指定排序依据。数据库不知道你所谓“最新”是指上架时间、ID 还是其他字段。必须显式用 ORDER BY create_time DESC（或 shelf_time DESC）告诉它按什么排。
常见错误现象：ROW_NUMBER() 返回的序号全是 1，或顺序随机；根本原因是缺 ORDER BY 子句。
- 使用场景：商品表有
category（类目）、create_time（上架时间）、id（主键）等字段 - 推荐排序字段优先级：先用业务定义的上架时间字段（如
shelf_at），没有再退到create_time，避免用id（自增不等于上架顺序） - 注意时区：如果
create_time是TIMESTAMP WITHOUT TIME ZONE，且应用写入时未统一时区，可能跨天错乱
用 ROW_NUMBER() 而不是 RANK() 或 DENSE_RANK()
当两个商品同秒上架，RANK() 会并列 1 然后跳到 3，DENSE_RANK() 并列 1 后直接是 2——但你要的只是“每个类目取一条”，不关心并列怎么编号。用 ROW_NUMBER() 更稳妥，它强制唯一编号，即使时间相同也会按内部顺序分出先后（具体顺序依赖数据库实现，但至少能返回一条）。
示例语句：
SELECT * FROM (
SELECT *,
ROW_NUMBER() OVER (
PARTITION BY category
ORDER BY shelf_at DESC, id DESC
) AS rn
FROM products
) t WHERE rn = 1;
-
shelf_at DESC, id DESC是双重保险：时间相同时，取 ID 更大的（通常更晚插入） - 某些数据库（如 MySQL 8.0+、PostgreSQL、SQL Server）支持该语法；SQLite 需 3.25+ 且开启窗口函数
- Oracle 中
ROW_NUMBER()行为一致，但旧版本可能需用ROWNUM配合子查询，不推荐
WHERE 条件必须写在窗口函数外层，不能在 OVER() 里加过滤
有人试图写 ROW_NUMBER() OVER (PARTITION BY category ORDER BY shelf_at DESC WHERE status = 'on_shelf')——这语法根本不存在。WHERE 是 SQL 执行阶段早于窗口函数计算的，必须先过滤再开窗。
- 正确做法：在子查询或 CTE 中先
WHERE status = 'on_shelf'，再对结果开窗 - 性能影响：如果原表很大但有效商品少，提前过滤能显著减少窗口计算量
- 容易踩的坑：漏掉下架商品过滤，导致“最新”结果实际是已下架的脏数据
MySQL 5.7 及更早版本不支持窗口函数，得用关联子查询替代
如果你卡在 MySQL 5.7，ROW_NUMBER() 直接报错 FUNCTION xxx.ROW_NUMBER does not exist。此时只能用左连接或相关子查询模拟：
SELECT p1.* FROM products p1
WHERE NOT EXISTS (
SELECT 1 FROM products p2
WHERE p2.category = p1.category
AND p2.shelf_at > p1.shelf_at
);
- 这个写法逻辑清晰：找不出同类别中上架时间更晚的商品，那它就是最新的
- 缺点：无索引时性能差，
(category, shelf_at)复合索引可大幅优化 - 注意 NULL：如果
shelf_at允许为空，需额外加AND p2.shelf_at IS NOT NULL，否则 NULL 会被认为“更大”
实际线上环境常遇到时间精度不足（秒级）、批量导入导致时间重复、以及类目字段存在空值或拼写不规范等问题。这些不会让 SQL 报错，但会让“最新”结果偏离预期——建议上线前用 SELECT category, COUNT(*), MIN(shelf_at), MAX(shelf_at) FROM products GROUP BY category 快速探查数据分布。
