子查询必须用括号包裹，否则语法报错；加权随机需用RANDOM()*weight等实现概率采样，而非仅ORDER BY weight；相关子查询易致性能问题，应改用LATERAL或APPLY；注意NULL、类型转换及版本兼容性。
子查询必须用括号包裹，否则语法直接报错
SQL里嵌套子查询不是写完就完事，最基础但最容易忽略的点是：任何子查询出现在 WHERE、FROM 或 SELECT 中，都必须用一对圆括号包住。比如想从用户表里随机挑一个权重高的任务执行人，写成 WHERE user_id IN SELECT id FROM users ORDER BY weight DESC LIMIT 1 会直接报错——缺括号、缺别名、没加 LIMIT 在非派生表上下文也不合法。
正确写法是：WHERE user_id IN (SELECT id FROM users ORDER BY weight DESC LIMIT 1)。注意这里 ORDER BY + LIMIT 能生效，是因为它在子查询内部；如果放在外层，就和“随机”目标冲突了。
用 RANDOM() 或 NEWID() 实现加权随机，不能只靠 ORDER BY weight DESC
按权重排序取第一个，只是“取最高权重者”，不是“按权重概率随机”。要实现加权随机（比如权重 3 的人被选中的概率是权重 1 的人的 3 倍），得把权重转成累积分布，再结合随机数采样。PostgreSQL 可用 RANDOM()，SQL Server 用 NEWID()，MySQL 8.0+ 推荐 RAND() 配合窗口函数。
- PostgreSQL 示例（加权随机抽一人）：
SELECT id, name FROM users ORDER BY RANDOM() * weight DESC LIMIT 1;
这里RANDOM() * weight让高权重项更大概率获得更大排序值 - 如果必须用子查询嵌套（比如要在 UPDATE 中指定分配人），就得用派生表：
UPDATE tasks SET assignee_id = ( SELECT id FROM ( SELECT id, RANDOM() * weight AS score FROM users ) t ORDER BY score DESC LIMIT 1 ); - 注意：
RANDOM()每行独立计算，所以不用担心重复或偏移
子查询中引用外部表字段时，容易触发相关子查询性能问题
如果任务表 tasks 每条记录都要基于当前任务类型查一次对应权重规则，写成：(SELECT user_id FROM users u WHERE u.role = t.task_type ORDER BY RANDOM() * u.weight DESC LIMIT 1)，这就成了相关子查询——每扫一条 tasks 就执行一次子查询，数据量大时极慢。
优化思路是提前物化权重映射，或者改用 LATERAL（PostgreSQL）或 APPLY（SQL Server）：
- PostgreSQL
LATERAL写法更清晰可控：SELECT t.id, u.id AS assignee_id FROM tasks t, LATERAL ( SELECT id FROM users u WHERE u.role = t.task_type ORDER BY RANDOM() * u.weight DESC LIMIT 1 ) u;
- 避免在子查询里反复计算
RANDOM()多次——它每次调用都生成新值，可能导致排序不稳定（尤其配合GROUP BY或窗口函数时）
MySQL 用户注意：8.0 之前不支持窗口函数，ORDER BY RAND() * weight 有隐式类型转换陷阱
MySQL 5.7 及更早版本不支持 ROW_NUMBER() 或 SUM() OVER()，强行做加权随机只能靠变量模拟累积权重，极易出错。而即使升级到 8.0，RAND() * weight 如果 weight 是字符串或 NULL，结果会变成 NULL，整行被排除——不会报错，但分配结果莫名变少。
- 务必显式转换并处理空值：
ORDER BY RAND() * COALESCE(CAST(weight AS DECIMAL), 0) DESC - 测试时用
SELECT id, weight, RAND() * COALESCE(CAST(weight AS DECIMAL), 0) AS score FROM users LIMIT 5;看一眼实际计算值，比盲调更可靠 - 生产环境慎用
ORDER BY RAND()类写法查大表——MySQL 会为每一行计算随机值并临时排序，内存和 CPU 开销陡增
加权随机分配真正难的不是语法，而是确认“权重是否已归一化”“NULL 值是否参与计算”“数据库版本是否真支持你写的那个函数变体”——这些细节不验证，跑得通的 SQL 也可能在某个凌晨三点悄悄漏掉 20% 的任务。
