空字符串''和null在join中永远不匹配，是sql标准行为；必须在on子句中对两边字段做一致归一化转换，如coalesce(nullif(trim(a.key), ''), null) = coalesce(nullif(trim(b.key), ''), null)，否则关联必然失败。
空字符串 '' 和 NULL 在 JOIN 中永远不匹配，不是数据问题，是 SQL 标准行为；必须在 ON 子句中对两边字段做**一致的归一化转换**，否则关联必然失败。
JOIN 条件里 '' 和 NULL 为什么连不上
因为 '' = NULL、NULL = NULL、'' = '' 这三种比较中，前两者结果都是 UNKNOWN，只有最后一个是 TRUE。SQL 的 JOIN 只认 TRUE，其余一律跳过。所以哪怕左表是 ''、右表也是 ''，能连上；但只要一边是 ''、另一边是 NULL，或两边都是 NULL，就断开。
常见现象：LEFT JOIN 后右表字段全为 NULL，但查原始数据发现左表存的是 ''，右表存的是 NULL——看着都“空”，实际根本没触发连接。
- 不能只转换一边，比如只对左表用
NULLIF(col, '')，右表不动，依然不匹配 -
COALESCE(col, '')没用：它把NULL变成''，但无法处理已有的''，反而让两类值更难统一 - 别依赖
TRIM()单独使用：TRIM(NULL)还是NULL，照样不参与匹配
用 NULLIF + COALESCE 统一转为 NULL
推荐写法：COALESCE(NULLIF(a.key, ''), NULL) = COALESCE(NULLIF(b.key, ''), NULL)。核心是 NULLIF(col, '')：当 col 是 '' 时返回 NULL，否则原样返回；而 NULL 输入时也直接返回 NULL，天然兼容。
COALESCE(..., NULL) 是冗余但显式兜底，语义清晰，可省略；重点是两边都做同样操作。
- 如果字段还含空格（如
' '），得先TRIM()：NULLIF(TRIM(a.key), '') - CHAR 类型字段可能右补空格，
TRIM()必须加，否则''永远不等于RTRIM(col) - HiveSQL 中
NULLIF可用，但注意旧版 Hive 对空字符串隐式处理较松，建议显式测试
WHERE 过滤前必须先标准化，否则漏行
JOIN 完之后想筛出“真正有值”的记录，直接写 WHERE phone != '' 会漏掉 NULL 行，WHERE phone IS NOT NULL 又漏掉 '' 行。
正确做法是复用归一化逻辑：WHERE NULLIF(phone, '') IS NOT NULL。它把 '' 和 NULL 都转成 NULL，再用 IS NOT NULL 判断，等价于“排除所有空白态”。
- 别用
LENGTH(phone) > 0：遇到NULL时返回NULL，整行被过滤 - 别用
phone > ''：同理，在NULL上结果为UNKNOWN - 如果业务要求“空字符串也算有效”，那就反向处理：用
COALESCE(phone, '') != ''，但要注意COALESCE不处理''本身
性能陷阱：函数索引或预清洗不可少
在 ON 或 WHERE 里用 TRIM()、NULLIF() 会阻止普通索引生效，大数据量时容易全表扫描。
解法分两种：
- 有函数索引支持（PostgreSQL / MySQL 8.0+ / SQL Server）：建索引时直接套函数，例如 PostgreSQL：
CREATE INDEX idx_users_phone_clean ON users (NULLIF(TRIM(phone), '')); - 无函数索引时，用 CTE 或子查询预清洗：
WITH clean_a AS (SELECT id, NULLIF(TRIM(phone), '') AS jk FROM users) SELECT * FROM clean_a JOIN clean_b USING (jk); - MySQL 老版本（ALTER TABLE users ADD COLUMN phone_clean STRING GENERATED ALWAYS AS (NULLIF(TRIM(phone), '')) STORED; 再对
phone_clean建索引
真实场景里最容易被忽略的是 CHAR 字段的右填充空格、JSON 字段解析后返回空字符串而非 NULL、以及 LEFT JOIN 后右表字段既可能是 NULL（未匹配），也可能是 ''（匹配上了但值为空）——这两类“空”语义完全不同，不能一并处理。
