COALESCE和IFNULL仅处理NULL值替换，无法解决数值溢出问题；溢出发生在写入或计算阶段，数据库类型校验时即拒绝或截断，函数根本不会执行。
COALESCE 和 IFNULL 不能修复“NULL 值溢出”——因为根本不存在这种错误类型。 SQL 中没有 “NULL 值溢出” 这一错误。你看到的 NULL，是 LEFT JOIN 逻辑本身产生的（右表无匹配行），或是字段真实缺失；而“溢出”是数值超范围（如 INT 存不下 3000000000）导致的报错，比如 Out of range value 或 numeric field overflow。两者成因、现象、解法完全不同，混用会误导排查方向。
为什么 COALESCE 无法解决数值溢出问题
COALESCE 是表达式级空值替换函数，只在查询执行末期处理结果值；而数值溢出发生在写入或计算阶段，数据库在类型校验时就已拒绝或截断。它连执行到 COALESCE 的机会都没有。
- 插入超限值时：语句直接失败（严格模式）或静默截断（如 MySQL 非严格模式下把
300 <code>TINYINT变成255），COALESCE根本不参与 - 算术运算中：若
tax_rate是NULL，price * tax_rate得NULL—— 这是 NULL 传播，不是溢出；但若tax_rate是超限值（如999.999插入DECIMAL(5,2)），插入那一刻就报错了 -
COALESCE(col, 0)对溢出列无效：它不能把一个已经因溢出被拒绝的值“拉回来”
LEFT JOIN 后字段为 NULL，该不该用 COALESCE 填充
可以填，但必须明确目的和边界——它只是视觉/展示层兜底，不改变数据事实。
- 适合场景：API 返回、报表导出、前端渲染，避免空单元格或 JS 报错
- 典型写法：
SELECT u.name, COALESCE(o.total, 0) AS total FROM users u LEFT JOIN orders o ON u.id = o.user_id - 关键限制：别在
WHERE里对COALESCE结果做等值判断，否则LEFT JOIN退化为INNER JOIN（例如WHERE COALESCE(o.status, 'draft') = 'shipped'会丢掉所有没订单的用户） - 类型要一致：PostgreSQL 中
COALESCE(created_at, 'N/A')会因TIMESTAMP和TEXT类型冲突报错；应改用COALESCE(created_at::TEXT, 'N/A')或统一转字符串
真正遇到“数字溢出”，优先检查这三处
数值溢出是建表设计或写入逻辑问题，不是查询层能绕过的。
- 查字段定义：
DESCRIBE orders或\d orders看total列是否为INT却要存上亿金额——应改为BIGINT或DECIMAL(18,2) - 查写入语句：是否有未校验的用户输入或外部数据直插，比如 Java 用
int接收再插入，却忽略了Integer.MAX_VALUE边界 - 查数据库模式：MySQL 生产环境必须启用
STRICT_TRANS_TABLES，否则溢出会静默截断，导致数据失真却无报错
最容易被忽略的是：把“JOIN 产生 NULL”和“数值写入溢出”当成同一类问题去套函数。前者是关系代数的必然结果，后者是类型系统在拦你。一个该在 SELECT 里修饰，一个该在 INSERT 前掐断。
