where col = null永远不生效，必须用is null，因为null是未知状态而非值，=比较结果恒为unknown，而where只保留true行；空字符串''是确定值，可用=''判断，与null语义和行为完全独立。
WHERE col = NULL 永远不生效，必须用 IS NULL
因为 SQL 标准规定：任何与 NULL 的等值比较（=、!=、）结果都是 UNKNOWN，而 WHERE 子句只保留 TRUE 的行。所以 col = NULL 实际上永远不匹配任何记录。
常见错误现象：
- 写
WHERE phone = NULL查不到手机号为空的用户 - ORM 自动生成的
WHERE field = None（如 Django 的filter(field=None)）在底层可能被误译为= NULL，需确认生成 SQL 是否用了IS NULL
正确写法只有两种：col IS NULL 或 col IS NOT NULL。别无替代。
空字符串 '' 是具体值，可用 = '' 直接判断
'' 是长度为 0 的合法字符串，属于确定值，参与所有常规比较运算。它和 NULL 在语义、存储、索引行为上完全独立。
使用场景举例：
- 表单允许提交空内容，后端未做
TRIM或非空校验，入库就是'' - ETL 脚本把缺失字段显式赋值为
''，而非留空或设为NULL - 某些数据库（如 Oracle）会把
''自动转成NULL，但 PostgreSQL/MySQL/SQL Server 不会——跨库迁移时极易出错
注意：col = '' 只命中空字符串，不会包含 NULL；反过来，col != '' 也不会包含 NULL 行（因为 NULL != '' 是 UNKNOWN），实际效果是“排除了 ''，但没动 NULL”。
COUNT(col) 统计逻辑暴露根本差异
COUNT(col) 只统计 col IS NOT NULL 的行，对 NULL 视而不见；但它会把 '' 当作一个有效值计入——除非你用的是 Oracle，它把 '' 当 NULL 处理。
性能与兼容性影响：
- Oracle：写
COUNT(phone)同时漏掉NULL和''；想统计“有实质内容”的号码得额外加WHERE phone != '' - MySQL/PostgreSQL：同样写法会把
''算进去，导致“有手机号用户数”虚高 - Impala/Hive：严格区分，
COUNT(phone)计''不计NULL，必须用SUM(CASE WHEN phone IS NULL OR phone = '' THEN 1 ELSE 0 END)才能合并统计
这个函数行为是最容易暴露业务口径偏差的地方——前端说“填了才算”，DBA 看 COUNT 结果却以为都算进去了。
统一处理要用 NULLIF 或 COALESCE，不能靠 =
当业务上希望把 NULL 和 '' 都当作“无数据”处理（比如清洗、去重、聚合前过滤），不能靠拼条件，得用函数兜底。
实操建议：
- 把空字符串转为
NULL：用NULLIF(col, '')—— 安全，且后续所有IS NULL、COUNT、GROUP BY行为都一致 - 把
NULL转为空字符串：用COALESCE(col, '')—— 注意：如果col原本就是''，COALESCE不触发替换，所以它不能合并二者 - 真正合并判断（NULL 或 ''）：写
COALESCE(col, '') = ''，或更清晰的col IS NULL OR col = ''
最容易被忽略的一点：很多团队在建模层直接用 WHERE col != '' 过滤“无效值”，却忘了 NULL 行也被悄悄放过了——这种漏查在线上跑半年都未必被发现。
