MySQL存储过程中RAND()×weight排序取TOP1错误，因RAND()单次查询返回相同值；正确方案是用窗口函数计算累积权重，再通过RAND()*总权重定位，需过滤零权重并处理浮点精度与空值。
MySQL存储过程中不能直接用 RAND() * weight 排序取 TOP 1
因为 RAND() 在单条 SELECT 中对所有行返回同一个值，根本不是“每行独立随机”；即使加了 ORDER BY RAND() * weight，结果也会严重偏向低权重项——数学上，RAND() * weight 的期望值随 weight 增大而增大，但你真正需要的是高权重项更可能生成小排序值。直接乘法是方向性错误。
用累积权重 + 二分查找是 MySQL 8.0+ 最稳的方案
核心思路：先算出总权重 S，再生成 RAND() * S 作为目标偏移量，最后在按权重累加的有序序列中定位该偏移落在哪一行。MySQL 8.0 支持窗口函数，可避免临时表或多次子查询。
- 必须先过滤掉
weight 的行，否则累计和失效 - 用
SUM(weight) OVER (ORDER BY id)计算前缀和，别用自连接（性能差且易错） - 目标值用
RAND() * (SELECT SUM(weight) FROM t WHERE weight > 0)，不能复用子查询别名 - 定位时用
ROW_NUMBER() OVER (ORDER BY cum_weight)配合WHERE cum_weight >= target取最小匹配行，等价于二分下界
示例片段（抽 1 条）：
SELECT id, name FROM (
SELECT id, name, weight,
SUM(weight) OVER (ORDER BY id) AS cum_weight,
ROW_NUMBER() OVER (ORDER BY id) AS rn
FROM tasks WHERE weight > 0
) t1
CROSS JOIN (SELECT RAND() * (SELECT SUM(weight) FROM tasks WHERE weight > 0) AS target) t2
WHERE t1.cum_weight >= t2.target
ORDER BY t1.cum_weight LIMIT 1;权重极小、为负或全零时会崩，必须提前兜底
负权重会让前缀和跳跃、反转，导致 cum_weight 序列不单调，二分失效；权重为 0.001 这类浮点小数，在累加过程中可能因精度丢失破坏区间连续性；若所有 weight 都是 0 或 NULL，SUM() 返回 NULL，整个 RAND() * NULL 结果为 NULL，WHERE 条件永远不成立。
- 强制加
WHERE weight > 0.0001（根据业务容忍度调阈值） - 用
COALESCE(SUM(weight), 0)包裹总和，并在外层判断是否为 0 - 若总权重为 0，直接
SELECT NULL或抛出自定义错误（SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'No valid weight found'） - 别依赖
DECIMAL自动修复浮点误差——累加过程仍走 DOUBLE，必须显式CAST(weight AS DECIMAL(18,6))
要抽多条不重复结果？别用 LIMIT N，得用递归 CTE 或临时表标记
指数采样法（如 -LN(1-RAND())/weight）天然支持无放回，但 MySQL 不支持该写法中的行级独立 RAND()（RAND(CHECKSUM(NEWID())) 是 SQL Server 特性）。想抽 3 条不重复，靠 LIMIT 3 会大概率重复——因为每次 RAND() 独立生成，三条都可能命中同一行。
- 最简方案：用临时表存候选集，每次抽 1 条后
DELETE对应id，循环 3 次（适合小数据量） - 高性能方案：用递归 CTE 生成 3 个不同
RAND()值，各自做一次二分查找，再UNION ALL后去重（注意加DISTINCT ON (id)或外层GROUP BY id） - 绝对禁止：在同一个
SELECT中多次调用RAND()并期望它返回不同值——MySQL 不保证
真正难的不是公式，而是每一步中间值的类型控制、空值防御、以及并发场景下任务被重复领取——如果这个加权随机用于分配工单，记得在最终 UPDATE 时加上 WHERE status = 'pending' AND id = ? 双重校验。
