row_number() 无法直接实现权重比例轮询分配，需通过累积和或重复展开将权重转化为可排序序列；推荐用加权累积值结合mod运算匹配任务序号与处理者区间，注意排序稳定性、总权重预计算及大规模场景下的分页或预计算优化。
ROW_NUMBER() 本身不支持权重排序，必须配合 ORDER BY 的表达式转换
直接在 ROW_NUMBER() 的 ORDER BY 里写权重字段（比如 ORDER BY priority DESC）只能实现静态优先级排序，无法实现“按权重比例轮询分配”。真正要按权重分任务，得把权重转化为可排序的虚拟序列号——常见做法是用累积和（cumulative sum）或重复展开（expand-then-rank）。
例如：有 3 个处理者，权重分别是 A:3、B:2、C:1，理想分配序列应为 A→B→A→C→A→B……共 6 个槽位。这时不能只靠 ROW_NUMBER() OVER (ORDER BY weight DESC)，它只会固定排成 A,A,A,B,B,C。
实操建议：
- 若数据量小、权重整数且不大（如总和 ≤ 1000），用
UNION ALL+VALUES展开每个处理者对应次数的行，再套ROW_NUMBER() - 若需实时计算、权重可能为小数或动态变化，改用窗口函数计算加权累积值：
SUM(weight) OVER (ORDER BY some_stable_key)，再结合任务序号取模映射 - 避免在
ORDER BY中使用非确定性表达式（如NEWID()或RAND()），否则ROW_NUMBER()结果不可复现，导致任务重复或遗漏
用 ROW_NUMBER() + MOD 实现加权轮询（适合中小规模任务队列）
核心思路：给每个任务生成全局递增序号，对「权重总和」取模，再匹配到对应权重区间内的处理者。这需要先预计算权重累计边界，再关联任务序号。
假设处理者表 handlers 含 id、weight，任务表 tasks 含 id；目标是为每条任务分配一个 handler。
关键步骤：
- 用
SUM(weight) OVER (ORDER BY id)计算每个 handler 的权重右边界（cum_weight） - 用
ROW_NUMBER() OVER (ORDER BY tasks.id)给任务编号（task_rn） - 用
(task_rn - 1) % total_weight + 1得到归一化位置（从 1 开始） - LEFT JOIN handlers ON 归一化位置 BETWEEN 上一 cum_weight+1 和当前 cum_weight
注意：total_weight 需提前查出（可用子查询或 CTE），且 handler 表必须有稳定排序依据（如 id），否则累计和顺序不确定。
常见错误：ORDER BY 用错字段导致分配倾斜
典型现象：本该按 3:2:1 分配，结果变成 5:1:0，或每次执行结果不一致。
原因往往出在 ROW_NUMBER() 的 ORDER BY 子句：
- 用了无索引、高重复值字段（如
status），导致排序不稳定，ROW_NUMBER()分配随机 - 漏写
ORDER BY中的次级键（如只写ORDER BY weight DESC，但 weight 相同的 handler 未加id排序），引发引擎自由选择顺序 - 在分布式数据库（如 Citus、TiDB）中，未确保
ORDER BY字段能被下推到分片本地排序，导致全局序号错乱
验证方法：单独运行 SELECT id, weight, ROW_NUMBER() OVER (ORDER BY weight DESC, id) FROM handlers，检查序号是否与权重分布预期一致。
性能陷阱：大表上直接 ROW_NUMBER() + JOIN 易 OOM 或超时
当任务表有百万级以上行，又强行用 CTE 先算全部 ROW_NUMBER() 再 JOIN handler 累计边界，内存和临时表空间压力极大。
更可行的做法：
- 放弃一次性全量分配，改用应用层分页拉取：每次查
SELECT * FROM tasks WHERE assigned_to IS NULL ORDER BY id LIMIT 100，再用程序做加权轮询分配 - 在任务插入时就预计算分配结果（如触发器或应用逻辑），写入
assigned_handler_id字段，查询走索引 - 用物化视图或定时 job 预生成「未来 N 小时」的任务分配映射表，避免实时计算
真实场景中，加权分配逻辑越靠近业务代码越可控；硬塞进单条 SQL 容易在数据增长后突然崩掉，而且难以 debug 分配偏差。
