SQL如何给分组后的数据添加行号 ROW_NUMBER分组排序
给分组数据加行号，ROW_NUMBER() 是首选工具，但用不对，结果要么报错，要么混乱。关键在于理解它的完整语法和那些容易踩坑的细节。
ROW_NUMBER() OVER (PARTITION BY … ORDER BY …) 是唯一正确写法
直接写 SELECT ROW_NUMBER() FROM t 肯定行不通，系统会直接报错。必须记住，ROW_NUMBER() 必须和 OVER 子句成对出现，而 OVER 里面，ORDER BY 是绝对不能省略的——哪怕只是按主键排序。没有明确的排序依据，行号就失去了定义，数据库每次执行都可能给出不同的顺序，这显然不是我们想要的结果。
那么，如何实现“分组内编号”呢？秘诀在于 PARTITION BY。它指定了分组的字段，比如 PARTITION BY category，就意味着在每个 category 内部，行号都会从1开始重新计算。这里有个常见的混淆点：千万别把 PARTITION BY 写成 GROUP BY，两者虽然概念相似，但在窗口函数里是完全不同的语法。
还有一点需要警惕：不能在 WHERE 或 GROUP BY 子句中直接引用 ROW_NUMBER() 生成的别名。想基于行号进行过滤？必须得套一层子查询或者使用 CTE（公共表表达式）。
PARTITION BY指定分组字段，如PARTITION BY category表示每个 category 内独立编号ORDER BY必须存在，决定组内行号顺序，如ORDER BY created_at DESC- 不能在
WHERE或GROUP BY中直接引用ROW_NUMBER()别名，得套一层子查询或 CTE
想取每组最新一条？别只靠 ROW_NUMBER()=1
这个需求太常见了：找出每个用户最近的一次操作记录。很多人会自然地写出类似这样的语句：ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn，然后加上 WHERE rn = 1。逻辑上看没问题，对吧？但这里藏着一个陷阱：如果 updated_at 这个时间字段存在重复值，比如同一个用户有两条记录的时间戳完全相同，数据库会怎么排序？答案是，它没有确定的排序规则，可能导致返回多行，而不仅仅是预期的“最新一条”。
解决办法其实很明确，主要有两个思路：
- 最稳妥的，是在
ORDER BY子句里补充一个唯一字段作为“决胜局”。例如写成ORDER BY updated_at DESC, id DESC。这样，即使时间相同，也能根据ID确定唯一的先后顺序。 - 如果业务上可以接受从时间相同的记录里任意选一条，一些数据库（如 BigQuery、Snowflake）提供了更简洁的
QUALIFY子句。但在 MySQL 8.0+ 或 PostgreSQL 中，还是得老老实实用子查询来实现过滤。
MySQL 8.0+ 和 PostgreSQL 差异很小，但 SQL Server 要注意兼容模式
从标准语法上看，ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) 在这几个主流数据库中都得到了支持。但魔鬼藏在细节里，尤其是 SQL Server 的兼容性设置。
如果你在 SQL Server 上执行窗口函数时报了 Incorrect syntax near 'OVER' 这种错，别急着怀疑人生。很可能是数据库的兼容级别（compatibility level）设置得太低了。怎么查？运行一下 SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME() 就知道了。这个值必须大于等于 100（对应 SQL Server 2008 及以后版本），窗口函数才能正常工作。
再看另外两位：
- MySQL 5.7 及之前的版本完全不支持窗口函数，强行使用会收到
FUNCTION xxx.ROW_NUMBER does not exist这样的错误提示。 - PostgreSQL 在这方面是“老前辈”，从 8.4 版本就开始支持了。不过要注意，
PARTITION BY和ORDER BY的字段类型必须可比对，不能拿文本类型和整型混在一起排序。
性能隐患：没索引时 PARTITION BY + ORDER BY 会触发临时文件排序
语法对了，结果也对了，就万事大吉了吗？未必。性能问题可能正在暗处等着。当分组字段（PARTITION BY）和排序字段（ORDER BY）都没有合适的索引时，数据库引擎就不得不进行全表扫描，把数据全部拉到内存（或者更糟，磁盘临时文件）中进行分组和排序。面对海量数据表，这种操作轻则超时，重则可能导致内存溢出（OOM）。
优化之道非常直接：建立联合索引。这是提升此类查询性能最有效的手段。
- 针对
PARTITION BY a ORDER BY b这样的模式，最理想的索引是INDEX idx_a_b (a, b)。 - 如果需要倒序排列（
ORDER BY b DESC），MySQL 8.0+ 和 PostgreSQL 支持在索引定义中指定降序，如(a, b DESC)。SQL Server 则需要显式地使用CREATE INDEX ... (a, b DESC)语法。 - 切记，不要只建单列索引。一个
INDEX(a)加一个INDEX(b)，对于窗口函数的性能提升几乎毫无帮助，因为数据库无法高效地同时利用它们来完成分组和排序。
说到底，分组排序这个操作，看似简单，背后却牵扯到行号的稳定性、索引的命中率以及查询优化器的执行计划。PARTITION BY、ORDER BY 和索引，这三者如何组合，直接决定了结果是又快又准，还是又慢又错。任何一个细节的疏忽，都可能让整个查询偏离预期。
