SUM结果虚高是因JOIN导致一行变多行而重复累加，需用CTE预聚合切断行复制链，并显式控制DECIMAL精度避免隐式提升。
为什么SUM结果比预期大好几倍
不是数据本身超限，而是JOIN把一行变多行，SUM跟着重复累加。比如1个订单含3条明细，LEFT JOIN后这单就变成3行，SUM(sale_lines.price_paid)就把同一笔price_paid加了3次。
- 只要关联表存在一对多关系（如
sale→sale_lines或sale→cash_transactions），直接GROUP BY sale.currency_items_sold_in再SUM就必然失真 - 错误现象不是报错，是数值虚高——你查出“总收款150万”，实际只有50万，但日志里看不出异常
- 执行计划里如果
rows_examined远大于左表行数，基本可判定是JOIN膨胀导致的假聚合
用CTE预聚合切断行复制链
核心是不让明细表参与最终分组，先各自按sale_id算好再合并。CTE不是语法糖，是强制物理隔离聚合阶段的手段。
- 第一步：对
sale_lines按sale_id求和，产出sale_id → total_price_paid临时结果 - 第二步：对
cash_transactions同样按sale_id分别求received_amount和converted_amount和 - 第三步：用
sale主表LEFT JOIN这两个CTE结果，此时每行sale只对应1行聚合值，SUM不再翻倍
WITH line_sums AS (
SELECT sale_id, SUM(price_paid) AS total_price_paid
FROM sale_lines GROUP BY sale_id
),
tx_sums AS (
SELECT sale_id,
SUM(received_amount) AS total_received,
SUM(converted_amount) AS total_converted
FROM cash_transactions GROUP BY sale_id
)
SELECT s.currency_items_sold_in,
SUM(ls.total_price_paid) AS price_paid,
SUM(ts.total_received) AS total_received_amount,
SUM(ts.total_converted) AS total_converted_amount
FROM sale s
LEFT JOIN line_sums ls ON ls.sale_id = s.id
LEFT JOIN tx_sums ts ON ts.sale_id = s.id
GROUP BY s.currency_items_sold_in;别在应用层拼IN列表触发隐式溢出
有人想绕开JOIN，改用“查出一批order_id，再用WHERE id IN (...)查明细”，但拼2万个ID进SQL，max_allowed_packet可能截断语句，MySQL也可能放弃使用索引转为全表扫描。
- IN列表长度超过5000时，执行计划常出现
Using where; Using index消失，变成Using where - 拼接字符串生成SQL，若ID含负数或NULL，
IN (-1, NULL, 2)会导致整个条件失效（NULL参与比较结果恒为UNKNOWN） - 更稳的做法是：用
WHERE id BETWEEN ? AND ?分段，配合id单调主键，避免IN列表长度不可控
DECIMAL精度陷阱比整数溢出更隐蔽
就算没报Arithmetic overflow，DECIMAL(10,2)字段存99999999.99 * 1.01也会崩——中间计算自动升到DECIMAL(27,6)，插入时才截断报错，但你根本没在SQL里写过27位。
- 存储过程里所有参与运算的变量、参数、字面量，都得显式
CAST成目标精度，例如CAST(@amount AS DECIMAL(12,2)) / CAST(100 AS DECIMAL(12,2)) - 绝对不要依赖
100.0这种写法，SQL Server会把它当NUMERIC(3,1)，和DECIMAL(12,2)相除，结果精度失控 - 线上环境必须开
SET ARITHABORT ON和ANSI_WARNINGS ON，让这类问题暴露为错误，而不是静默失败
真正难防的不是SUM报错，是SUM不报错却算错。JOIN膨胀和DECIMAL隐式提升这两类问题，不会中断事务，但会让财务对账永远差一笔——而且你查日志、看监控、跑单测都发现不了。
