ROW_NUMBER() 必须配合 PARTITION BY 和 ORDER BY 才能实现分组内排序，否则仅为全局序号；需先明确活跃定义并过滤数据，再用数值型指标排序，避免逻辑混乱或性能瓶颈。
ROW_NUMBER() 必须配合 PARTITION BY 才能分组排名
不加 PARTITION BY 的 ROW_NUMBER() 只会全局排序，根本不会按分类算“每个分类内的排名”。这是最常踩的坑——写完发现所有用户排成一列，而不是每个分类从 1 开始重新计数。
正确姿势是：用 PARTITION BY category 切分组，再用 ORDER BY active_days DESC（或其他活跃指标）决定组内顺序。注意 ORDER BY 在窗口函数里是必需的，否则语法报错。
-
PARTITION BY后跟分类字段，比如category、product_type、region - 排序字段建议选数值型活跃指标，如
last_login_days_ago、login_count_7d；避免用user_name这类无业务意义的字段 - 如果同一分类内有并列活跃值，
ROW_NUMBER()仍会强制分配不同序号（比如 1,2,3），不跳过也不重复
活跃用户定义要提前明确，别在窗口函数里硬凑
很多人试图在 ROW_NUMBER() 的 ORDER BY 里直接写逻辑判断，比如 ORDER BY (CASE WHEN login_count_7d > 0 THEN 1 ELSE 0 END)，这会导致排名依据模糊——你排的是“是否活跃”，不是“有多活跃”。
真正有用的活跃用户排名，应该基于可量化、有梯度的指标。先在 WHERE 或子查询里筛出活跃用户（例如 login_count_7d >= 3），再对这批人排名，逻辑更清晰，结果也更可信。
- 常见活跃定义：
login_count_7d >= 1、last_login_time >= CURRENT_DATE - INTERVAL '7 days' - 若需排除测试账号或机器人，提前用
WHERE user_type NOT IN ('test', 'robot') - 别把
ROW_NUMBER()当过滤工具——它不改变数据行数，只加一列序号
性能敏感场景慎用 ROW_NUMBER() + 大表 JOIN
当分类维度基数高（比如几十万种 product_id），又叠加多表 JOIN，ROW_NUMBER() 窗口计算可能成为瓶颈。数据库要为每一组缓存排序中间结果，内存和 CPU 消耗陡增。
简单优化路径：先聚合再排名。比如先把用户按分类汇总出 active_score，生成临时结果集，再对这个小结果集跑 ROW_NUMBER()。比直接在千万级明细表上开窗快得多。
- 优先在
GROUP BY category, user_id后计算活跃分，再套窗口函数 - 确认执行计划中
WindowAgg节点没有出现在大表扫描之后（PostgreSQL）或Window Function没触发磁盘溢出（MySQL 8.0+） - MySQL 用户注意：
ROW_NUMBER()仅 8.0+ 支持，5.7 及更早版本必须用变量模拟，稳定性差
别混淆 ROW_NUMBER() 和 RANK() / DENSE_RANK()
如果业务要求“同分同名次”，比如两个用户活跃天数都是 12 天，都该排第 1 名，那 ROW_NUMBER() 就错了——它会给其中一个标 1、另一个标 2。这时候得换 RANK()（跳过后续名次）或 DENSE_RANK()（不跳过）。
但多数运营场景要的是“唯一序号”，比如发奖只取每类前 3 名，这时 ROW_NUMBER() 反而是刚需：确保严格取满 3 个，不因并列而少发或超发。
-
ROW_NUMBER()：1,2,3,4…（严格递增） -
RANK()：1,1,3,4…（并列后跳号） -
DENSE_RANK()：1,1,2,3…（并列后不跳号） - 检查需求文档里有没有“并列如何处理”的说明，没有就默认用
ROW_NUMBER()
实际用的时候，最容易被忽略的是活跃定义和窗口范围的一致性——比如用 7 天登录次数排名，但筛选条件写的是 30 天有登录，结果把低频用户也混进去了。这种偏差不会报错，但排名完全失真。
