利润贡献率计算需防null和除零：用coalesce转空值为0，nullif拦截分母为0，显式cast指定decimal精度；聚合与窗口函数需分步（cte）；where必须置于聚合前确保分子分母口径一致。
利润贡献率 = 业务线利润 ÷ 总利润，但 NULL 和 0 会直接让结果变 NULL 或报错
很多人写 SUM(profit) / SUM(SUM(profit)) OVER() 一跑就全 NULL，不是数据没值，是某条记录的 profit 为 NULL —— SQL 里任何数和 NULL 做算术运算都得 NULL。更麻烦的是，总利润为 0 时除零不报错但返回 NULL（PostgreSQL）或报错（MySQL 严格模式），线上查着查着就断了。
实操建议：
- 用
COALESCE(profit, 0)把空利润转成 0，别依赖前端补； - 总利润先算一遍存在 CTE 里，再用
NULLIF(total_profit, 0)拦住除零； - 比例结果显式转成
DECIMAL(5,4)或NUMERIC，避免浮点误差影响排序或前端展示。
GROUP BY 后不能直接用窗口函数，得套一层子查询或 CTE
想按 business_line 分组求各自利润，再除以总利润，写成 SELECT business_line, SUM(profit) / SUM(SUM(profit)) OVER() ... GROUP BY business_line 会报错：窗口函数不能出现在 GROUP BY 查询的 SELECT 列表里（除非也在 GROUP BY 中）。这不是语法偷懒，是 SQL 执行顺序决定的——聚合先于窗口计算。
实操建议：
- 用 CTE 先聚合出各业务线利润：
WITH line_profit AS (SELECT business_line, SUM(COALESCE(profit,0)) AS line_sum FROM orders GROUP BY business_line)； - 再在外部查里算总利润：
SELECT business_line, line_sum / NULLIF(SUM(line_sum) OVER(), 0) AS contribution_rate FROM line_profit； - 如果用 MySQL 8.0+ 或 PostgreSQL，CTE 可读性远好于嵌套子查询，别为了“省一层”硬写连表。
WHERE 过滤要放在聚合前，否则贡献率分母会被悄悄缩小
比如加了 WHERE status = 'completed'，你以为只过滤订单，实际是：先筛出 completed 订单 → 再按业务线求和 → 最后算占比。但如果漏掉这句，或者把它挪到 HAVING 里，分母就变成全部业务线总利润（含已取消订单），分子却是完成订单利润，贡献率加起来可能远小于 100%，老板一看就懵。
实操建议：
- 所有业务逻辑过滤（如状态、时间范围、渠道类型）必须写在最外层查询的
WHERE，且在第一个FROM后立即出现； - 不要在窗口函数里塞
FILTER (WHERE ...)来“局部过滤”，那只会让分子分母口径不一致； - 上线前用
SELECT SUM(COALESCE(profit,0))单独跑一次分母值，和报表里各线条之和手动对一遍。
不同数据库对 DECIMAL 除法精度处理不一致，别信默认小数位
PostgreSQL 默认除法返回 numeric，保留足够精度；MySQL 的 DECIMAL/DECIMAL 除法会截断小数位（比如 DECIMAL(10,2) / DECIMAL(10,2) 结果最多 4 位小数），导致 0.0015 算成 0.001；SQL Server 更狠，默认按被除数精度推导，经常丢末尾 0。
实操建议：
- 显式转类型：
CAST(line_sum AS DECIMAL(15,6)) / NULLIF(CAST(total AS DECIMAL(15,6)), 0)； - 在应用层（如 Python pandas）拿到结果后，用
round(x, 4)统一修约，别依赖数据库输出格式； - 如果要做环比、累加校验，务必确认所有环节用同一套精度规则，否则 99.99% + 0.02% = 100.00% 这种事真会发生。
真正卡人的从来不是公式多难，而是 NULL 怎么填、WHERE 放哪、小数点后几位由谁定——这些细节一旦在线上混用，贡献率数字看着合理，拆开一验就对不上。
