order by中权重字段排序不生效是因为未用窗口函数分组；正确写法是row_number() over (partition by group_id order by weight desc)，且需根据语义选rank()或dense_rank()，避免浮点误差和where误用。
ORDER BY 中用权重字段排序不生效？检查是否漏了窗口定义
直接在 ORDER BY 里写权重字段（比如 weight）只能做全局排序，不是“每组内按权重排”。真要分组加权排序，必须用窗口函数，且得明确指定 PARTITION BY 和 ORDER BY 子句。
- 常见错误现象：
SELECT *, ROW_NUMBER() OVER (ORDER BY weight DESC) FROM t—— 这是全表排，不是按组 - 正确写法必须带分组：
ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY weight DESC) - 注意：窗口函数的
ORDER BY是排序依据，PARTITION BY才决定“每组”的边界，二者缺一不可 - 如果业务要求相同权重时稳定排序，建议补上唯一键（如
id）：ORDER BY weight DESC, id ASC
权重归一化后再排序？小心浮点误差导致顺序错乱
有些场景会先算权重占比（比如 weight / SUM(weight) OVER (PARTITION BY group_id)），再按这个比例排序。但除法可能引入浮点精度问题，尤其当原始值是整数、分母大时，0.3333333333333333 和 0.3333333333333334 在排序中会被当成不同值。
- 使用场景：排行榜按“贡献度占比”排序，或 A/B 测试中按分流权重排序
- 推荐做法：避免中间归一化，直接用原始整型权重排序；若必须归一化，用
ROUND(..., 6)截断小数位 - 性能影响：多一层计算 +
ROUND会让执行计划增加 CPU 开销，大数据量时可观测执行时间变化 - 兼容性提示：PostgreSQL 14+ 对
ROUND(float8, int)优化较好；MySQL 8.0 的ROUND在窗口函数中支持完整，但早期版本慎用
ROW_NUMBER() vs RANK() vs DENSE_RANK()：权重相同时行为差异极大
权重字段常有重复值，选错编号函数会导致排名语义错误。比如两个用户权重都是 95，你希望他们并列第1名，还是一个占第1、一个占第2？这直接影响下游逻辑。
-
ROW_NUMBER()：严格递增，相同权重也会强行分先后（靠后续ORDER BY字段决定） -
RANK()：相同权重同名次，跳过后续名次（95→第1，95→第1，80→第3） -
DENSE_RANK()：相同权重同名次，不跳号（95→第1，95→第1，80→第2） - 容易踩的坑：用
ROW_NUMBER()做“Top N 每组”时，相同权重用户可能被随机踢出结果，而业务本意是“所有并列高权者都保留”
WHERE 里不能直接过滤窗口函数结果？得用子查询或 CTE
想查“每组权重前3的记录”，不能写 WHERE rn ，因为窗口函数在 SQL 逻辑执行顺序中晚于 <code>WHERE。直接写会报错 column "rn" does not exist 或提示无法在 WHERE 中引用别名。
- 正确做法只有两种：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY weight DESC) AS rn FROM t) t1 WHERE rn 或用 CTE
- 别用
HAVING替代——它只对GROUP BY生效，和窗口函数无关 - 性能提醒：子查询写法在 PostgreSQL 中通常能下推过滤，但 MySQL 5.7 及更早版本可能无法优化，导致全量计算窗口再过滤，数据量大时明显变慢
- 小技巧：如果只要取 Top 1，可用
NOT EXISTS关联自比较，有时比窗口函数更快，但可读性下降
事情说清了就结束。真正卡住人的，往往不是语法，而是没意识到窗口函数的执行时机比 WHERE 晚，或者没想清楚“相同权重”到底该不该并列。
