SQL空值处理：当COALESCE遇上空字符串，如何优雅兜底？
COALESCE能处理空字符串吗？不能，得先清理
先说一个核心结论：COALESCE 函数本身，是拿空字符串没办法的。它只认 NULL，不认空字符串 ''。为什么？因为在数据库眼里，空字符串是一个有效的字符串值，而 NULL 才代表“未知”或“缺失”。
这就导致了一个常见的业务场景：你信心满满地写下 COALESCE(col, 'N/A')，以为万无一失。结果前端页面还是显示一片空白，一查数据，字段里存的偏偏是 '' 而不是 NULL。函数忠实地执行了规则：第一个参数不是 NULL，所以直接返回它——那个空字符串。
那么，正确的解决思路是什么？其实很简单，分两步走：先把空字符串“变成” NULL，再交给 COALESCE 去处理。具体怎么变？
- 标准解法：绝大多数数据库（如 PostgreSQL、SQL Server、Oracle）都提供了
NULLIF(value1, value2)函数。当两个值相等时，它返回NULL。所以，组合拳就是：COALESCE(NULLIF(col, ''), 'N/A')。 - MySQL 注意事项：MySQL 同样支持
NULLIF()，写法一致。但要留意版本差异，尤其是老版本在空字符串和NULL的隐式转换上可能有些“小脾气”。 - 更严谨的清理：如果数据里还可能混杂着纯空格（比如
' '），光用NULLIF就不够了。这时候，需要先TRIM再判断：COALESCE(NULLIF(TRIM(col), ''), 'N/A')。这才是真正意义上的“数据清洗”。
为什么不用 CASE WHEN？性能和可读性怎么权衡
看到这里，你可能会问：用 CASE WHEN 语句不是更直白吗？比如 CASE WHEN col = '' OR col IS NULL THEN 'N/A' ELSE col END。确实，从功能上讲，它完全能实现。
但关键在于权衡。当逻辑变得复杂，或者需要处理多个字段时，CASE WHEN 会迅速膨胀，变得难以阅读和维护。而 COALESCE 的优势就在于它的简洁性和声明性——一眼就能看出“选取第一个非空值”的意图。而且，作为标准 SQL 函数，它在多数数据库引擎中都经过了优化，比如采用短路求值，性能上通常也有保障。
当然，COALESCE 也不是万能的，有几个坑需要注意：
- 类型兼容是前提：所有参数的类型必须兼容。如果你写
COALESCE(int_col, 'N/A')，在类型严格的数据库里会直接报错。 - MySQL 的类型推导：在 MySQL 中，
COALESCE的返回值类型由第一个非NULL参数决定，后面的参数会被强制转换，可能导致数据精度丢失。 - 适用场景：对于简单的“空值兜底”，
COALESCE+NULLIF的组合拳更优雅。但如果判断条件非常复杂（例如“空串或长度小于2或为特定关键字”），那么CASE WHEN的逻辑清晰度反而更高。
实际查询中容易漏掉的边界情况
理论很完美，现实却很骨感。生产环境的数据往往比测试数据“野”得多。下面这几个边界情况，一不小心就会踩坑：
- CHAR 类型陷阱：对于
CHAR(n)这种定长字符串类型，数据库会用空格填充不足的位数。这导致col = ''的判断永远为假。正确的做法是使用TRIM(col) = ''或RTRIM(col) = ''。 - JSON 与 TEXT 字段：处理 JSON 结构或大文本字段时更要小心。某些数据库的 JSON 函数（例如 PostgreSQL 的
json_extract_path_text）在路径不存在时可能返回空字符串而非NULL。你的空值处理逻辑必须覆盖到这一点。 - JOIN 后的“双重空”：进行左连接（LEFT JOIN）时，右表匹配不到的字段自然是
NULL。但如果右表对应字段里存的就是空字符串，情况就复杂了——数据既不是NULL，业务上又不应该展示为空。这需要在查询设计时就考虑到。 - ORM 框架的约定：应用层框架对“空”的定义直接影响数据库存储。例如，Django 模型中的
CharField(blank=True)允许表单为空，但存入数据库的是空字符串；而null=True才允许存储NULL。团队必须对齐这些约定，否则底层 SQL 怎么写都是错。
一个安全兜底的通用写法模板
经过上面的讨论，我们可以总结出一个相对安全、通用的字符串空值处理模板：
COALESCE(NULLIF(TRIM(col), ''), 'N/A')
这个写法在 PostgreSQL、SQL Server、Oracle、MySQL 8.0+ 等主流数据库中基本都能用。它依次解决了：去除首尾空格、将空字符串转为 NULL、最后为 NULL 提供一个默认值。
如果是数字字段呢？千万别套用 TRIM。通常的思路是用 NULLIF(col, 0)，但这里有个关键判断：0 在业务上是否代表“无数据”？ 如果 0 是一个合法的业务数值（比如账户余额就是 0），那么把它转为 NULL 就错了。这时，更稳妥的做法可能是显式的 CASE WHEN 来判断特定的“无效值”。
说到底，最棘手的往往不是 SQL 语法，而是对“空”的业务定义。数据库里存的，究竟是语义上的“缺失”，还是仅仅形式上的“空白”？团队如果没有达成共识，再精巧的 COALESCE 也拯救不了混乱的查询结果。在写任何兜底逻辑之前，不妨先问一句：我们到底想屏蔽什么？
