ROW_NUMBER()必须配合PARTITION BY和ORDER BY才能实现分组内独立编号；漏PARTITION BY会导致跨组连续编号，漏ORDER BY则语法报错或结果不可控；JOIN后应先对右表预编号再关联以避免性能问题。
ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 才能隔离多表联查的编号范围
多表 JOIN 后直接套 ROW_NUMBER()，编号会跨组连续（比如 A 表 3 条 × B 表 4 条 = 12 行，编号就是 1–12），这不是你想要的“每个 A 记录下独立给 B 编号”。关键在 PARTITION BY —— 它定义编号重置边界。你得用外键或逻辑分组字段做分区依据，比如 PARTITION BY a.id，这样每个 a.id 对应的所有 B 行才从 1 开始重新编号。
常见错误是漏写 ORDER BY：SQL 标准要求 ROW_NUMBER() 必须带 ORDER BY，否则报错；即使引擎允许（如旧版 MySQL），结果也完全不可预测。排序字段最好选确定性列（如 b.created_at 或 b.id），别用 SELECT * 后的模糊位置序号。
LEFT JOIN 场景下 ROW_NUMBER() 的 NULL 值处理陷阱
当主表 LEFT JOIN 从表，且某主表行无匹配从表记录时，ROW_NUMBER() 仍会为该空行生成一个编号（比如 1），但所有从表字段都是 NULL。这容易误判为“有数据”。实际中要主动过滤或标记：
- 加
WHERE b.id IS NOT NULL排除空关联行（如果只关心有匹配的数据） - 或在
ROW_NUMBER()外层用CASE WHEN b.id IS NULL THEN NULL ELSE ROW_NUMBER() OVER (...) END显式置空 - 注意：不能把
b.id放进PARTITION BY—— 它是 NULL，会导致所有空行被分到同一组，编号混乱
性能敏感时避免在大结果集上直接 ROW_NUMBER()
ROW_NUMBER() 是窗口函数，必须等整个 JOIN 结果集生成完毕才能开始编号。如果 A 表 10 万行、B 表平均匹配 50 行，中间结果达 500 万行，内存和排序开销极大。此时更优解是分步处理：
- 先用子查询或 CTE 把 B 表按
a_id预编号：SELECT b.*, ROW_NUMBER() OVER (PARTITION BY a_id ORDER BY id) AS rn FROM b - 再和 A 表
LEFT JOIN这个已编号的 B 子集 - 数据库能更好利用
a_id索引，且避免对全量笛卡尔积排序
尤其在 PostgreSQL 或 SQL Server 上，这种拆分常带来数倍性能提升。
不同数据库对 ROW_NUMBER() + JOIN 的兼容性细节
MySQL 8.0+ 和 PostgreSQL 没问题，但旧版 MySQL（FUNCTION xxx.ROW_NUMBER does not exist。SQLite 3.25+ 支持，但不支持 PARTITION BY（只能全局编号）。SQL Server 中若用 TOP N 配合 ROW_NUMBER()，必须把窗口函数放在子查询里，否则 TOP 会截断前编号 —— 正确写法是：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM ...) t WHERE rn 。
真正容易被忽略的是：JOIN 条件字段类型不一致（比如 a.id 是 BIGINT，b.a_id 是 INT）会导致隐式转换，使 PARTITION BY a.id 实际分组失效 —— 看似编号正常，但跨类型重复值可能被错误归入同一组。
