COALESCE不能处理空字符串，因其只识别NULL而非空字符串''；需先用NULLIF(col, '')将空串转为NULL，再嵌套COALESCE(NULLIF(col, ''), 'N/A')实现兜底。
COALESCE能处理空字符串吗？不能，得先清理
COALESCE 本身只按顺序返回第一个非 NULL 的值，它完全不识别空字符串 '' —— 因为 '' 是有效字符串，不是 NULL。所以如果你直接写 COALESCE(col, 'N/A')，而 col 存的是 ''，结果还是 ''，根本不会 fallback 到 'N/A'。
常见错误现象：前端显示一片空白，查数据库发现字段值是空字符串而非 NULL，但业务逻辑本意是“无数据”。
解决思路是把空字符串先转成 NULL，再交给 COALESCE：
- PostgreSQL / SQL Server / Oracle：用
NULLIF(col, '')把空串转为NULL，再套COALESCE(NULLIF(col, ''), 'N/A') - MySQL：同样支持
NULLIF()，写法一致；但注意 MySQL 8.0+ 才严格区分''和NULL，老版本可能有隐式转换陷阱 - 如果字段还可能含纯空格（如
' '），得先TRIM(col)，再NULLIF(TRIM(col), '')
为什么不用 CASE WHEN？性能和可读性怎么权衡
CASE WHEN 当然能实现相同逻辑，比如 CASE WHEN col = '' OR col IS NULL THEN 'N/A' ELSE col END，但它在多个字段或嵌套场景下迅速变臃肿。
COALESCE 的优势在于简洁、标准 SQL 兼容性好，且多数数据库对它做了优化（如 PostgreSQL 会短路求值）。但要注意：
- 所有参数必须类型兼容，否则触发隐式转换或报错（例如
COALESCE(int_col, 'N/A')在强类型引擎里会失败） - MySQL 中
COALESCE返回值类型由第一个非NULL参数决定，后续参数会被强制转成该类型，可能丢失精度 - 如果只是单字段兜底，
COALESCE+NULLIF更紧凑；涉及复杂条件（如“空串或长度CASE 更直白
实际查询中容易漏掉的边界情况
真实表数据往往比预期混乱，这几个点经常被忽略：
- CHAR 类型字段：右填充空格导致
col = ''永远为假，必须用TRIM(col) = ''或RTRIM(col) = '' - JSON 字段或 TEXT 字段：某些数据库（如 PostgreSQL）允许
NULL和空字符串共存，但 JSON 函数（如json_extract_path_text）可能返回空串而非NULL，需额外判断 - JOIN 后的字段：左连接时，右表字段为
NULL是正常的，但如果右表本身存了空串，就变成“双重空”——既不是NULL也不该展示为空 - 应用层 ORM 干预：比如 Django 的
CharField(blank=True)默认存空串，Laravel 的nullable()才存NULL，建表和代码约定要对齐
一个安全兜底的通用写法模板
针对字符串字段，兼顾空串、NULL、空格、类型安全的写法：
COALESCE(NULLIF(TRIM(col), ''), 'N/A')
这个组合在 PostgreSQL、SQL Server、Oracle、MySQL 8.0+ 均可用。如果字段是数字类型，别 TRIM，改用 NULLIF(col, 0) 或更谨慎的 CASE WHEN col = 0 THEN NULL ELSE col END —— 因为 0 可能是合法值，不能一概而论。
最麻烦的不是语法，而是团队对“空”的定义是否统一：数据库里存的是语义上的“缺失”，还是形式上的“空白”。这点不厘清，再漂亮的 COALESCE 也救不了查询结果。
