聚合函数溢出主因是计算路径卡在小类型内，必须在SUM/AVG/MAX内部提前CAST字段为大类型，而非对结果CAST；否则中间累加已溢出，CAST无效。
聚合函数溢出不是数据太大，而是计算路径卡在了小类型里。必须在进入 SUM、AVG、MAX 前就把字段转成足够大的类型，而不是对结果再 CAST。
为什么 CAST(SUM(col) AS BIGINT) 一定失败
溢出发生在 SUM() 内部加法阶段，此时数据库已按原始列类型（比如 INT）分配 32 位寄存器做累加。等它算出一个溢出值（例如 -2147483648），再 CAST 也救不回来。
- MySQL 5.7+ 中，
SUM(INT)中间结果仍是INT，哪怕你 SELECT 里写了CAST(SUM(...) AS BIGINT) - SQL Server 对
SMALLINT列执行HAVING SUM(col) > 32767会直接报错，因为SUM(SMALLINT)返回类型还是SMALLINT - 达梦、PostgreSQL 同理：类型推导只看输入列，不看外层包装
SUM 溢出的正确写法：CAST 必须包在聚合函数里面
目标是让加法运算全程在大类型空间里进行。不同数据库语法略有差异，但逻辑一致：
- MySQL：
SUM(CAST(amount AS BIGINT))或更稳妥的SUM(CAST(amount AS DECIMAL(18,2))) - PostgreSQL：
SUM(amount::BIGINT)或SUM(CAST(amount AS NUMERIC)) - SQL Server：
SUM(CAST(amount AS BIGINT)) - 如果字段本身是
UNSIGNED INT，别漏掉符号：用CAST(amount AS UNSIGNED BIGINT)（MySQL）或CAST(amount AS DECIMAL(20,0))（跨库兼容）
HAVING 和 WHERE 里的表达式同样要提前 CAST
过滤条件和聚合计算共享同一套类型推导链。只改 SELECT 里的 CAST，HAVING 仍走原始路径，照样溢出。
- 错误：
HAVING SUM(amount) > 1000000000——amount是INT，SUM中间就爆了 - 正确：
HAVING SUM(CAST(amount AS BIGINT)) > 1000000000 - JOIN 后聚合更危险：比如
LEFT JOIN orders ON ...后取orders.amount，若该列为NULL或隐式转换过，CAST 位置稍偏一点就失效
容易被忽略的边界点：中间类型查不到，得主动验证
别靠“看起来没问题”判断。SQL Server 可用 TYPE_NAME() 查实际类型，MySQL/PG 要结合执行计划看是否触发了隐式转换警告。
- 执行
SELECT TYPE_NAME(SUM(CAST(XSCL_XSCL AS BIGINT)))确认返回类型真是bigint - MySQL 开发环境务必启用
STRICT_TRANS_TABLES，否则溢出会静默截断为最大值（比如 300 → 255），比报错更难排查 - 如果源数据可能含非法字符（如字符串混数字），优先用
TRY_CAST（SQL Server）或SAFE_CAST（BigQuery），避免整条 SQL 崩掉
