mysql数值运算溢出时默认不报错：插入依赖sql_mode，表达式计算如sum()或+号会按内部有符号64位整型推导，超限后回绕或转null；需启用strict_trans_tables才报错。
MySQL数值运算溢出时默认行为是什么
MySQL对数值溢出的处理不统一：插入单个值到列中，是否报错取决于 sql_mode；而表达式计算（如 SUM()、+）则按内部类型推导，**即使列是 BIGINT，中间计算仍可能用有符号64位整型，超限后直接回绕或转为 NULL（取决于版本和模式）**。比如：SELECT 9223372036854775807 + 1; 在多数 8.0+ 实例返回 NULL 或警告，而非期望的 -9223372036854775808。
必须开启 STRICT_TRANS_TABLES 才能捕获溢出错误
仅靠把字段改成 BIGINT 不能防止溢出失败——它只扩大存储上限，不改变 SQL 执行时的校验逻辑。真正起作用的是运行时 SQL 模式：
-
STRICT_TRANS_TABLES：对事务表启用严格模式，溢出时抛出ERROR 1264 (22003): Out of range value for column 'xxx' -
STRICT_ALL_TABLES：对所有表生效，但非事务表可能部分写入后回滚，风险更高 - 生产环境应设为
STRICT_TRANS_TABLES,NO_ZERO_DATE,NO_ZERO_IN_DATE，避免静默截断 - 检查当前模式：
SELECT @@sql_mode;；临时设置：SET sql_mode = 'STRICT_TRANS_TABLES';；永久修改需改my.cnf中的sql_mode配置项
用 DECIMAL 替代 BIGINT 做聚合计算更安全
当需要确保加总、累乘等运算不溢出，且精度不可丢失（如金额、计数器），BIGINT 仍有硬上限（±9.2×10¹⁸）。此时 DECIMAL 是更可控的选择：
-
DECIMAL(20,0)可存最大99999999999999999999（20位整数），远超BIGINT上限 - 所有算术操作在 DECIMAL 内部按定点数执行，不会因中间结果溢出而失效
- 代价是 CPU 运算稍慢、索引体积略大，但对绝大多数业务写入/查询无感
- 注意：不要用
DECIMAL存 ID（主键/外键），因字符串比较逻辑与整型不一致，且 ORM 映射易出错
应用层做预校验比依赖数据库更可靠
数据库严格模式只拦住 INSERT/UPDATE，拦不住 SELECT 表达式溢出，也拦不住应用侧自己算错再写入。真实线上问题常出现在：
- 批量导入时，某条记录的
amount * quantity超出BIGINT，但因未开严格模式，被静默截成负数 - Java 用
long接收BIGINT，但前端传了 20 位字符串 ID，后端没校验就直接拼 SQL，导致隐式转换溢出 - 监控缺失：没有定期跑
SELECT MAX(col), MIN(col) FROM t WHERE col > 9223372036854775800 OR col
关键点在于：溢出不是“会不会发生”的问题，而是“什么时候暴露”的问题。越晚发现，数据失真越难追溯。别把 sql_mode 当万能开关，它只是最后一道闸门。
