溢出发生在SUM()中间累加阶段，而非结果赋值时；必须用SUM(CAST(col AS BIGINT))提前升类型，CAST(SUM(col) AS BIGINT)无效，因溢出后CAST根本无法执行。

溢出不是因为数据太大，而是数据库在 SUM() 执行过程中用错了中间计算类型——它默认按原始列类型做累加，加到第 2147483648 就炸，根本不会等你 CAST 结果。

为什么 CAST(SUM(col) AS BIGINT) 无效

错误堆栈里看到的 Arithmetic overflow error converting expression to data type int 不是发生在 SELECT 输出时，而是 SUM() 内部某次累加就崩了。执行顺序是：先用 col 的原始类型（比如 INT）逐行相加 → 中间值超限 → 报错退出 → CAST 根本没机会运行。

• ✅ 正确写法：SUM(CAST(col AS BIGINT)) —— 每行进聚合前就升类型
• ❌ 错误写法：CAST(SUM(col) AS BIGINT) —— 聚合完才转，为时已晚
• SQL Server 中 TYPE_NAME(SUM(col))、PostgreSQL 中 pg_typeof(sum(col)) 可验证实际中间类型，别只看 MAX(col)

SUM() 在 JOIN 后更危险

一对多关联（如用户 → 订单明细）会让同一数值被重复读取多次，行数暴增直接放大中间累加次数。原本 10 万行 INT 安全，JOIN 后变成 500 万行，就容易触到中间类型的上限。

• 别在 LEFT JOIN 后直接写 SUM(o.amount)，尤其当 o.amount 是 SMALLINT 或 DECIMAL(9,2)
• 先用 CTE 或子查询预聚合：SUM(CAST(amount AS DECIMAL(18,2)))，再和主表关联
• o.amount 含 NULL 时，隐式类型推导可能收缩精度，必须显式 CAST

不同数据库对中间类型的处理差异极大

没有“自动升级”这回事。各库都按原始列类型硬算中间值，且规则不一致：

• SQL Server：对 SMALLINT 列的 SUM()，中间类型仍是 SMALLINT，不是 INT
• MySQL 5.7+：SUM(INT) 默认走 32 位整数计算；若未开 STRICT_TRANS_TABLES，可能静默截断而非报错
• PostgreSQL / 达梦：同样不会拓宽，MAX(block_id * 8192 + bytes) 溢出就得写成 MAX(CAST(block_id AS DECIMAL) * 8192 + bytes)
• MONEY 类型尽量换掉——四舍五入规则不透明，中间步骤就可能失真

最麻烦的不是加不加 CAST，而是上线后才发现某些分组的中间类型比预想的还小：比如两个 DECIMAL(9,2) 相加，结果精度被压缩，而你只查了 MAX(col)，没验证 SUM() 的中间类型。