子查询中直接除法易因NULL或除零报错或返回NULL；应使用NULLIF(denominator,0)避免除零，再用COALESCE(numerator/NULLIF(denominator,0),0)确保结果为0，并对参与字段先COALESCE(col,0)处理NULL。
子查询里直接除法会出错：注意 NULL 和除零
在 SQL 中用子查询算权重占比时，最常见的错误是 SELECT ... / (SELECT SUM(...)) 这种写法遇到分母为 0 或含 NULL 就返回 NULL 或报错。比如订单表里某类目销量全为 0，外层一除就整个结果变空。实际要加保护：用 NULLIF 拦住除零，再用 COALESCE 补默认值。
-
NULLIF(denominator, 0)把 0 变成NULL，避免除零错误 -
COALESCE(numerator / NULLIF(denominator, 0), 0)确保结果至少是 0 - 所有参与计算的字段先用
COALESCE(col, 0)处理NULL，别依赖外层聚合自动忽略
权重分配必须用窗口函数？不一定，但得看场景
如果只是按某个维度（如地区）算各自占总销售额的比例，用关联子查询完全够用；但若要“给每个用户分配与其历史购买力成正比的预算”，且需排除异常高值用户（比如 Top 1% 截断），这时候就得嵌套两层子查询：第一层算分位数阈值，第二层用该阈值过滤后再算占比。窗口函数在这里不是必需，但会让逻辑更清晰、性能更好——尤其当数据量超百万行时，子查询可能被重复执行多次。
- 简单占比（全局或单维度）：
(SELECT SUM(sales) FROM orders)一次查完即可 - 带条件动态基准（如“仅统计近30天活跃用户”）：子查询里必须复现相同
WHERE条件，否则基准和分子不匹配 - 想避免子查询重复执行：把基准值提前算好，用
WITH公共表表达式（CTE）引用，兼容 PostgreSQL / SQL Server / BigQuery
MySQL 8.0 以下不能用 CTE？那就用派生表模拟
老版本 MySQL 不支持 WITH，但可以用 FROM (SELECT ...) 写派生表来缓存中间结果。关键点在于：这个子查询必须起别名（哪怕叫 t），否则语法报错；而且不能在 WHERE 或 ON 里直接引用派生表字段做关联——得包一层再 JOIN。
SELECT u.name, u.score / t.total_score AS weight FROM users u CROSS JOIN ( SELECT COALESCE(SUM(score), 0) AS total_score FROM users WHERE status = 'active' ) t;
- 别用
SELECT * FROM (subquery)直接嵌套，MySQL 5.7 会报 “Every derived table must have its own alias” - 如果需要按组算权重（如每部门内占比），老版本只能靠相关子查询：
(SELECT SUM(score) FROM users u2 WHERE u2.dept = u1.dept)，性能差但可行 - 确认执行计划里没出现
DEPENDENT SUBQUERY—— 出现意味着每行都重跑子查询，数据量大时秒变卡死
浮点精度误差会影响分配结果吗？会，而且很隐蔽
用 DECIMAL(10,4) 存原始值，但子查询里直接除，结果可能有微小误差（比如 0.3333333333333333）。当你要把权重转成整数配额（如 100 个资源按权重分给 3 人），四舍五入后加起来可能变成 99 或 101。这不是 bug，是浮点本质问题。
- 分配前先归一化：把所有权重相加，再用
ROUND(weight / total_weight * 100, 0)算百分比份额 - 最后用“最大余数法”补足总数：把小数部分最大的几个项 +1，确保总和严格等于目标值
- 业务上允许误差时，加
ROUND(..., 4)控制小数位，比默认 double 更可控
权重计算本身不难，难的是让每一步的边界条件都显式处理——尤其是 NULL、零值、精度、版本兼容性，这些地方漏一个，上线后就容易分错资源。
