聚合字段类型转换错误的关键在于cast必须置于聚合函数内部而非外部，如sum(cast(col as bigint))而非cast(sum(col) as bigint)，否则中间累加仍按原始类型运算导致溢出。
聚合字段类型转换错误，本质不是 CAST 写得不对，而是 CAST 没写在该写的位置——漏掉任意一个计算节点，溢出或截断就照常发生。
为什么 CAST(SUM(col) AS BIGINT) 一定失败
数据库在执行 SUM() 时，中间累加过程严格按原始列类型分配寄存器空间。比如 col 是 INT，那整个加法链全程用 32 位有符号整数运算，一旦超过 2147483647，结果直接翻转为负数或报错。此时再套一层 CAST 已无意义——损坏发生在内部，外部无法修复。
- MySQL 5.7+、SQL Server、达梦、PostgreSQL 全部遵循此规则，不因数据库而异
-
HAVING SUM(col) > 1000000000这类条件同样走原始类型路径，光改SELECT不够 - LEFT JOIN 后取某表数值列，若该列含
NULL，可能触发隐式类型重推，让原本有效的CAST失效
SUM / AVG / MAX 必须在聚合函数最内层 CAST
目标是让所有算术运算、比较、累加都在目标精度范围内进行。关键动作是把 CAST 包在聚合函数参数里，且覆盖所有涉及该字段的表达式节点。
- 正确写法：
SUM(CAST(salary AS BIGINT))、AVG(CAST(price AS DECIMAL(18,2)))、MAX(CAST(block_id AS DECIMAL) * 8192 + bytes) - 错误写法：
CAST(SUM(salary) AS BIGINT)、AVG(CAST(AVG(price) AS DECIMAL)) - 若字段是
UNSIGNED INT，应转UNSIGNED BIGINT，否则隐式符号转换可能引发异常 - 变量赋值时也需同步处理：
SELECT @total = CAST(SUM(CAST(amount AS DECIMAL(18,2))) AS DECIMAL(18,2))
TEXT/NTEXT 字段参与聚合必须显式转 VARCHAR(MAX)
TEXT 类型不支持比较、排序、哈希，因此不能用于 GROUP BY、DISTINCT、ORDER BY 或任何聚合函数。这不是配置问题，是类型能力缺失。
- 临时方案：用
CAST(text_col AS VARCHAR(MAX))，注意必须是MAX，写成VARCHAR(8000)会无声截断 - Unicode 内容优先用
NVARCHAR(MAX)：CAST(text_col AS NVARCHAR(MAX)) - 长期解法：用
ALTER TABLE table_name ALTER COLUMN col_name VARCHAR(MAX)迁移列类型（NTEXT对应NVARCHAR(MAX)） - 执行前检查是否有
DEFAULT约束或绑定规则，若有需先DROP再ADD
JOIN 字段类型不一致导致的聚合异常
当聚合字段来自 JOIN 结果（尤其是 LEFT JOIN），而 JOIN 键本身类型不一致时，隐式转换不仅影响性能，还会干扰后续聚合的类型推导路径。
- 查清两边字段定义：
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_SET_NAME, COLLATION_NAME, IS_NULLABLE FROM INFORMATION_SCHEMA.COLUMNS - 任一差异（类型、字符集、校对集、是否允许 NULL）都可能让索引失效或类型推导出错
-
ON u.id = CAST(o.user_id AS BIGINT)这类写法掩盖问题，B+ 树索引无法命中，EXPLAIN 显示type: ALL - 根治方式是统一字段类型，包括字符集和校对集，外键需先
DROP再重建
真正难的不是写出那一行 CAST，而是意识到它需要出现在每一个计算节点：SELECT、HAVING、WHERE（如果涉及聚合后过滤）、变量接收、甚至窗口函数的帧内运算。漏掉任何一个，错误就还在那里等着你。
