ROW_NUMBER() 本身不支持加权，需通过ORDER BY构造加权表达式实现；正确做法是将多字段合并为单个数值型、非空、可比的合成值（如score0.6+clicks0.4），并显式处理NULL和类型转换。
ROW_NUMBER() 本身不支持加权，得靠 ORDER BY 构造权重逻辑
ROW_NUMBER() 只是按 ORDER BY 的结果顺序编号，它不计算分数、不加权。所谓“加权排名”，本质是把多个条件转换成一个可排序的合成值（比如加权得分），再用 ROW_NUMBER() 去排这个值。
常见错误是直接写 ROW_NUMBER() OVER (ORDER BY score * 0.6, clicks * 0.4) —— 这不是加权排序，而是先按 score * 0.6 排，相等时才看 clicks * 0.4，属于多级排序，不是线性加权。
- 真正加权要合并为单个表达式：
score * 0.6 + clicks * 0.4 - 注意字段类型：如果
score是INT、clicks是BIGINT，乘以小数前建议显式转FLOAT或DECIMAL，避免整数截断 - NULL 值会污染加权和：建议用
COALESCE(score, 0)显式处理
多字段排序 ≠ 加权排名，但常被混用
当业务说“按销量优先、其次好评率、最后上架时间”，这是典型的多级排序需求，不是加权。此时应直接用 ORDER BY sales DESC, rating DESC, listed_at DESC，再套 ROW_NUMBER()。
- 多级排序中，后序字段只在前序字段值相等时生效
- 字段间不能“抵消”：哪怕好评率极低，只要销量高，就排前面；加权则可能因好评率拖累总分
- 性能上，多级排序对复合索引友好（如
(sales, rating, listed_at)）；加权表达式通常无法走索引，需全表计算
加权表达式要防溢出、防 NULL、防精度丢失
比如用 views * 0.1 + shares * 5 + comments * 2 给内容打分，看似合理，但实际执行时容易出错：
-
shares和comments是整型，乘以整数常量没问题；但0.1是NUMERIC，可能触发隐式转换，不同数据库行为不一（PostgreSQL 会升为NUMERIC，MySQL 可能截断） - 用
CAST(views AS DECIMAL(18,2)) * 0.1比直接写views * 0.1更可控 - 所有参与字段必须
COALESCE(x, 0)，否则整个加权和为NULL，ROW_NUMBER()会把这些行排到最后（且顺序不确定） - 示例安全写法：
ROW_NUMBER() OVER (ORDER BY COALESCE(views, 0) * 0.1 + COALESCE(shares, 0) * 5.0 + COALESCE(comments, 0) * 2.0 DESC)
分区加权排名要注意权重逻辑是否跨组有效
加权排名常配合 PARTITION BY 使用（如“每个类目内加权排名”）。这时权重系数是否该统一？比如电子产品类目点击价值高，服装类目转化率更重要——就不能共用一套权重。
- 若需动态权重，得提前用
CASE WHEN category = 'electronics' THEN ... ELSE ... END构造加权项 - 不要在
OVER()子句里写PARTITION BY后再试图“按类目调整系数”，窗口函数不支持分区级参数化 - 更稳妥的做法：先用
JOIN或 CTE 把权重系数查出来，作为列参与加权计算
加权排名的核心不在 ROW_NUMBER()，而在你构造的那个 ORDER BY 表达式——它得是数值型、非空、可比、且符合业务意义。系数调几轮、NULL 处理漏没漏、类型隐式转换踩没踩坑，往往比窗口函数本身更决定结果对不对。
