cast(sum(col) as bigint)无法解决溢出，因sum(int)中间累加在32位寄存器中已溢出；必须用sum(cast(col as bigint))确保全程64位运算。
为什么CAST(SUM(col) AS BIGINT)根本救不了溢出
报错不是因为结果太大，而是加法过程在32位寄存器里就炸了。数据库对 SUM(INT) 的中间累加全程按 INT 类型执行，一旦超过 2147483647，立刻变成负数或直接报错——此时再套 CAST 只是对一个错误值做无意义转换。
常见错误现象包括：ERROR 1690 (22003): BIGINT UNSIGNED value is out of range（MySQL）、Arithmetic overflow error converting expression to data type int（SQL Server）、numeric field overflow（PostgreSQL）。
- MySQL 5.7+ 中，
SUM(INT)返回类型仍是INT，外层CAST不改变计算路径 - SQL Server 对
SMALLINT列执行HAVING SUM(col) > 32767会直接中断，因SUM(SMALLINT)默认返回SMALLINT - 达梦、PostgreSQL 同理：类型推导只看输入列，不看外层包装
SUM(CAST(col AS BIGINT)) 是唯一有效写法
必须把 CAST 塞进聚合函数最内层，让整个加法运算在64位空间里进行。这不是“选不选”的问题，是计算链路的硬性要求。
不同数据库写法略有差异，但核心一致：
- MySQL：
SUM(CAST(amount AS BIGINT))（CAST(amount AS SIGNED)在部分版本等价，但不推荐，易混淆） - PostgreSQL：
SUM(amount::BIGINT)或SUM(CAST(amount AS BIGINT)) - SQL Server：
SUM(CAST(amount AS BIGINT)) - 若字段是
UNSIGNED INT，必须转UNSIGNED BIGINT，否则隐式符号转换可能引入负值
示例（分组场景）：
SELECT dept_id, SUM(CAST(salary AS BIGINT)) AS total_salary FROM employees GROUP BY dept_id;
HAVING、WHERE 和变量赋值也得同步改类型
光修 SELECT 里的 SUM 不够。只要表达式涉及该字段的任何计算节点，都独立走一次类型推导——漏掉任意一个，溢出就还在那里。
-
HAVING条件必须写成HAVING SUM(CAST(salary AS BIGINT)) > 1000000000，而非HAVING CAST(SUM(salary) AS BIGINT) > 1000000000 -
JOIN后聚合要小心：LEFT JOIN 可能引入NULL，建议先COALESCE(col, 0)再CAST - SQL Server 存储过程中赋值给变量时，声明类型必须匹配：
DECLARE @total BIGINT，且赋值语句显式SELECT @total = SUM(CAST(amount AS BIGINT)) - 上线前用
TYPE_NAME()和PRECISION()验证中间结果类型，别只看数值是否“看起来正常”
别指望改表结构一劳永逸
把源字段从 INT 改成 BIGINT 看似彻底，但现实约束很多：已有应用依赖原类型、迁移成本高、权限受限、或只是临时报表需求。
更关键的是：即使改了表结构，如果字段参与了表达式运算（比如 block_id * 8192 + bytes），仍可能因中间乘法溢出——这时得写成 CAST(block_id AS DECIMAL) * 8192 + bytes，而不是只靠字段定义。
真正难的不是写对那行 CAST，而是意识到所有计算节点——GROUP BY 键、WINDOW 帧内运算、甚至 ORDER BY 排序依据——都可能各自触发一次类型推导。漏掉任意一个，溢出就还在那里等着你。
