SQL中空字符串''与NULL不等价：''是长度为0的确定值，NULL表示未知；二者比较结果为UNKNOWN，JOIN时无法匹配；需用NULLIF+COALESCE统一转为NULL处理，避免混淆。
SQL JOIN时空字符串和NULL不等价，必须显式对齐
空字符串 '' 和 NULL 在 SQL 中是完全不同的值：前者是长度为 0 的字符串，后者表示“未知”。标准 SQL 中，'' = NULL 返回 UNKNOWN（即逻辑假），所以直接用 ON a.key = b.key 关联时，哪怕两边都是空字符串或一边空一边 NULL，都会被跳过——这不是 bug，是规范行为。
常见错误现象：LEFT JOIN 后发现本该匹配的记录变 NULL，查字段却发现左表是 ''、右表是 NULL，或反过来；导出数据后在 Excel 里看着都“空”，但数据库里根本连不上。
- 统一思路：在
JOIN条件中把空字符串和NULL映射到同一个占位值（如'<null>'</null>），或全部转为NULL - 推荐做法是转为
NULL，因为语义更干净，且多数聚合函数（如COUNT()、AVG()）天然忽略NULL - 避免用
COALESCE(col, '')去“补空”，这会让NULL变成''，反而加剧不一致
用NULLIF + COALESCE在JOIN条件中做标准化
NULLIF(col, '') 是关键：它在 col 等于 '' 时返回 NULL，否则返回原值。再配合 COALESCE 可兜底处理已有的 NULL（虽然 NULLIF 已保留原 NULL，但写全更清晰）。
实操示例（以两个用户表按手机号关联为例）：
SELECT u1.name, u2.email FROM users_v1 u1 LEFT JOIN users_v2 u2 ON COALESCE(NULLIF(u1.phone, ''), NULL) = COALESCE(NULLIF(u2.phone, ''), NULL);
说明：
-
NULLIF(u1.phone, '')把u1.phone中的''转成NULL，NULL保持不变 -
COALESCE(..., NULL)是冗余但安全的写法（可省略），重点在前半部分 - 两边都做同样转换，才能让
''和NULL在比较时“相等” - 注意：不能只转换一边，否则仍不匹配
WHERE过滤前先标准化，避免漏掉空值行
如果关联后还要加 WHERE（比如查“手机号不为空的用户”），直接写 WHERE phone != '' 会漏掉 NULL 行，而 WHERE phone IS NOT NULL 又会漏掉 '' 行。必须先标准化再判断。
正确写法：
SELECT * FROM users WHERE NULLIF(phone, '') IS NOT NULL;
等价于“排除 '' 和 NULL”，因为 NULLIF(phone, '') 对 '' 返回 NULL，对 NULL 也返回 NULL，只有非空非 NULL 字符串才返回自身，再用 IS NOT NULL 判断。
- 别用
WHERE phone > ''或WHERE LENGTH(phone) > 0，前者在某些方言（如 MySQL）中对NULL返回NULL导致整行被过滤，后者对NULL返回NULL同样失效 - 如果业务上允许空字符串有意义（如“用户明确留空”），那就不能盲目转
NULL，得加额外标记字段区分
建表或ETL阶段就固化空值策略，别总靠运行时转换
每次查询都套 NULLIF 不仅难读，还影响索引使用（表达式列无法直用普通索引）。长期方案是在源头控制：
- 建表时对字符串字段加
CHECK (col IS NULL OR col != '')，强制业务层不插入空字符串（PostgreSQL / SQL Server 支持） - 导入数据时用
INSERT ... SELECT COALESCE(NULLIF(raw_col, ''), NULL)清洗 - 若用 Hive/Spark SQL，可在视图里封装标准化逻辑，下游只查视图
- MySQL 用户注意：
NULLIF可用，但STRICT_TRANS_TABLES模式下空字符串插入可能被截断或报错，需检查 SQL mode
最易被忽略的是：当关联字段有索引时，NULLIF(col, '') 会导致索引失效——除非你建函数索引（PostgreSQL/MySQL 8.0.13+ 支持），否则性能下降明显。
