SUM()报错“算术溢出”是因SQL Server聚合时自动推导的中间类型过小：INT列求和中间类型仍为INT，超2147483647即溢出；需在SUM内显式CAST（如CAST(SUM(col) AS BIGINT)），而非仅声明变量或外层转换。
为什么SUM()一执行就报错“算术溢出”？
不是数据本身太大，而是SQL Server在聚合时自动推导的中间类型太小。比如对一个INT列做SUM()，结果类型默认还是INT——哪怕你查出来的最大值才100万，但只要整组加起来超过2147483647，立刻炸。这跟最终目标字段类型无关，是计算过程中的隐式类型决定的。
- 用
TYPE_NAME(SUM(col))和PRECISION(SUM(col))查实际中间类型，别只看MAX(col) -
INT列求和 → 中间类型是INT；SMALLINT列求和 → 中间类型仍是INT（不会升到BIGINT） - 聚合前不显式转换，等于把命交给SQL Server猜——它经常猜错
CAST(SUM(...))必须写在SELECT里，不能只改变量声明
很多人声明了DECLARE @total DECIMAL(18,2)，然后写SELECT @total = SUM(col) FROM ...，以为够了。错：赋值前的SUM(col)已经按原始列类型算完了，溢出发生在赋值之前。
- 正确写法：
SELECT @total = CAST(SUM(col) AS DECIMAL(18,2)) FROM ... - 如果后续要插入表，目标字段是
DECIMAL(12,2)，CAST就必须严格匹配：CAST(SUM(col) AS DECIMAL(12,2))，不能图省事写DECIMAL(18,2) - 聚合字段本身是
MONEY？立刻换成DECIMAL——MONEY四舍五入规则不透明，容易在中间步骤悄悄失真
GROUP BY场景下容易漏掉的隐式转换点
分组统计时，常把SUM()嵌在子查询或CTE里，再外层JOIN或过滤。这时候溢出可能发生在子查询内部，而错误堆栈只显示最外层语句，排查成本陡增。
- 在子查询里就加
CAST：SELECT id, CAST(SUM(amount) AS BIGINT) AS total FROM t GROUP BY id - 别依赖外层
CONVERT补救——外层根本收不到溢出前的结果 - 如果分组键来自表达式（如
DATEADD(day, -7, gmt_create)），确保该表达式结果不会因类型推导引发额外溢出（比如datetime参与算术运算可能隐式转成INT毫秒计数）
TRY_CAST对SUM()无效，别白费力气
TRY_CAST(SUM(col) AS INT)不会返回NULL，而是直接报错。因为SUM()执行失败在先，TRY_CAST根本没机会介入。
-
TRY_CAST只对单值转换安全，对聚合函数不适用 - 真要兜底，得在聚合前截断或过滤：
SUM(CASE WHEN col - 或者用
ISNUMERIC()+CASE筛掉异常值——但注意ISNUMERIC()误判率高，优先用TRY_CONVERT()判断原始数据质量
最麻烦的不是不会修，而是修完上线才发现某些分组的SUM()中间结果类型比预想的还小——比如两个DECIMAL(9,2)相加，结果可能是DECIMAL(10,2)，但SQL Server有时会按DECIMAL(10,3)算，再CAST时精度不匹配照样溢出。这类细节必须用TYPE_NAME()实测，不能靠经验猜。
