row_number() 不支持直接加权排序，必须通过 order by 中的 case 或算术表达式将权重转化为可比较值，注意处理 null、类型一致性和性能优化。
ROW_NUMBER() 本身不支持直接加权排序
ROW_NUMBER() 是一个窗口函数，它只按 ORDER BY 子句产生的逻辑顺序严格编号，不接受权重系数、乘法或表达式权重。所谓“按权重排序”，本质是把权重转化为可比较的排序依据——你得先用权重影响 ORDER BY 的表达式，再套 ROW_NUMBER()。
用 CASE 或算术表达式把权重“编译”进 ORDER BY
常见场景是给不同分类赋予优先级：比如状态为 'urgent' 的排最前，'pending' 次之，'done' 最后。这时不能写 ROW_NUMBER() OVER (ORDER BY weight_column) 就完事——因为 weight_column 很可能不是数值型，或数值含义和排序方向相反。
- 用
CASE显式映射权重等级：ROW_NUMBER() OVER (ORDER BY CASE status WHEN 'urgent' THEN 1 WHEN 'pending' THEN 2 WHEN 'done' THEN 3 ELSE 4 END, created_at DESC) - 若已有数值型权重列（如
priority_score），注意方向：ORDER BY priority_score DESC才让高分靠前；写成ASC就反了 - 混合多维权重时，可加权求和（需归一化或控制量级）：
ORDER BY (score * 0.6 + votes * 0.4) DESC，但要警惕整数截断和 NULL 传播
NULL 值和类型不一致会悄悄破坏排序结果
权重计算中一旦出现 NULL，整个 ORDER BY 表达式结果就为 NULL，而所有 NULL 在默认排序中被视作相等且排在最前（ASC）或最后（DESC），极易导致编号错乱。例如：CASE WHEN flag THEN 1 ELSE NULL END 会让未命中分支全挤在一块编号。
- 强制非空：用
COALESCE(weight_expr, 999)或ISNULL(weight_expr, 999)（SQL Server）补默认值 - 统一类型：
CASE各分支返回相同类型，避免隐式转换（如混用1和'2'）引发排序异常 - 验证排序键：先单独查
SELECT id, [你的权重表达式] AS sort_key FROM table，确认值分布和 NULL 情况
性能敏感时别在 ROW_NUMBER() 里做复杂计算
如果权重逻辑涉及子查询、UDF 或多表 JOIN，把它塞进 ORDER BY 会导致窗口函数执行时反复计算，严重拖慢。特别是数据量大、并发高时，ROW_NUMBER() 本身就要全量扫描并排序，再叠加计算开销更明显。
- 提前物化权重：用 CTE 或派生表先算出带权重列的结果集，再对其应用
ROW_NUMBER() - 建计算列或索引：对稳定权重表达式建持久化计算列，并在该列上建索引（如 SQL Server 支持
PERSISTED） - 避免在
ORDER BY中调用标量函数（如dbo.CalculateWeight(id)），它们无法向量化，且难优化
实际排序逻辑是否真正反映业务权重，取决于你如何构造 ORDER BY 表达式——ROW_NUMBER() 只是忠实编号员，不会替你判断哪个值“更重”。
