SQL的JOIN本身不支持按权重比例分配，需结合窗口函数（如SUM() OVER()）计算累计区间，再通过CROSS JOIN与随机数匹配实现；注意浮点精度、空值及RAND()重复调用问题。
JOIN 本身不支持权重比例分配，得靠窗口函数 + JOIN 搭配实现
SQL 的 JOIN 是关系匹配操作，只管“是否关联”，不管“分多少”。想按权重（比如某字段值占总和的百分比）把主表一条记录拆分到多个目标行，JOIN 单独做不到。必须引入 ROW_NUMBER()、SUM() OVER() 或 NTILE() 等窗口函数预计算比例，再用 JOIN 做逻辑绑定。
用 CROSS JOIN + 累计权重区间判断最可控
典型做法是：先算出目标表每行的权重占比（如 weight / SUM(weight) OVER()），再转成前缀累计区间 [start, end)；主表每条记录生成一个 RAND() 或序列号，通过 CROSS JOIN 后用 WHERE rand_val >= start AND rand_val 匹配归属。关键点：
-
CROSS JOIN要加WHERE过滤，否则笛卡尔爆炸 - 累计区间必须用
LAG() OVER(ORDER BY ...)或自连接严格保证不重不漏 - PostgreSQL/SQL Server 支持
RANDOM()或NEWID()，MySQL 8.0+ 用RAND()，但注意其在 JOIN 中可能被多次求值 - 示例片段：
SELECT t.id, w.target_id FROM orders t CROSS JOIN ( SELECT target_id, COALESCE(SUM(weight) OVER(ORDER BY target_id ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING), 0) AS start_p, SUM(weight) OVER(ORDER BY target_id ROWS UNBOUNDED PRECEDING) AS end_p, SUM(weight) OVER() AS total_w FROM targets ) w WHERE RAND() * w.total_w >= w.start_p AND RAND() * w.total_w < w.end_p;
用 LATERAL（或 APPLY）避免全量 CROSS JOIN 更高效
如果数据库支持 LATERAL（PostgreSQL、SQL Server 的 APPLY），可把权重匹配逻辑下推到每行执行，避免主表 × 目标表的全量膨胀：
- PostgreSQL 示例：
SELECT t.id, w.target_id FROM orders t, LATERAL ( SELECT target_id FROM targets ORDER BY ABS(RANDOM() - (weight::float / SUM(weight) OVER())) LIMIT 1 ) w;
- 这不是严格按比例抽样，而是概率轮盘赌式分配；若需强一致性比例，仍推荐累计区间法
- SQL Server 用
CROSS APPLY替代LATERAL，语法稍异但语义相同 - 注意
LATERAL子查询里不能直接引用外部表聚合（如SUM() OVER()需提前物化进 CTE）
常见翻车点：浮点精度、空权重、重复随机数
实际跑通后容易在生产环境突然偏斜，问题往往藏在细节里：
- 权重字段为
INT时，weight / SUM(weight)在整数除法下恒为 0（MySQL/SQL Server 默认行为），必须显式转FLOAT或乘1.0 - 存在
weight = 0的行，累计区间会断层，需提前WHERE weight > 0过滤 - 某些方言（如旧版 MySQL）中
RAND()在同一语句中多次调用返回相同值，导致所有行都分到同一个 target —— 必须用RAND() * SUM()一次性算出标量再比较 - 当目标权重极不均衡（如 99% : 1%），小权重项可能长时间抽不到，需确认业务能否接受这种方差
真实场景里，权重分配不是“写个 JOIN 就完事”的事；它本质是概率采样或确定性分片，得根据数据库能力选对路子——累计区间法最稳，LATERAL 法更省资源，但两者都要亲手掐住浮点、空值和随机数这三个开关。
