NULL和空字符串''在MySQL中语义不同，必须分开判断处理：查NULL用IS NULL，查''用= ''，聚合时COUNT忽略NULL但计入''，CONCAT遇NULL返回NULL而遇''返回拼接结果。
空值（NULL）和空字符串（''）在 MySQL 中不是一回事，混用会直接导致查询漏数据、条件失效、统计偏差——必须分开判断、分开处理。
WHERE 条件里怎么写才能查到 NULL 或 ''
用 = 或 != 判断 NULL 永远返回 false，这是最常见的翻车点。
- 查
NULL：必须用WHERE phone IS NULL，不能写WHERE phone = NULL - 查空字符串：用
WHERE phone = ''，不能写WHERE phone IS NULL（这会漏掉真实存了''的记录） - 想同时查两者：
WHERE phone IS NULL OR phone = ''，注意中间是OR，不是AND - 如果字段被定义为
NOT NULL，但又允许插入''，那它就永远不会是NULL—— 这时IS NULL永远查不到结果
INSERT 和 UPDATE 时，'' 和 NULL 写法不同但效果可能被 MySQL 自动“修正”
某些场景下 MySQL 会悄悄把 '' 当成 NULL 处理，尤其是字段带 NOT NULL 约束但没设默认值时。
- 显式插入：
INSERT INTO users(name) VALUES ('')和INSERT INTO users(name) VALUES (NULL)是两条不同的语句 - 但如果列定义是
name VARCHAR(50) NOT NULL，再执行INSERT INTO users(name) VALUES ('')，MySQL 会报错或（取决于 SQL mode）自动转成NULL—— 即使你没写NULL - 更隐蔽的是：如果列有
DEFAULT ''，而你INSERT INTO users() VALUES ()，它真存的是''；但如果列是DEFAULT NULL，同一条语句存的就是NULL - 用
UPDATE赋值时也一样：SET phone = ''和SET phone = NULL效果不同，但若该列不允许NULL，后者会失败
聚合与计算时，NULL 和 '' 行为完全不同
NULL 在多数函数中会“传染”，而 '' 是个普通字符串值，参与运算不报错但结果可能不符合预期。
-
COUNT(phone)会忽略NULL，但会计入''；COUNT(*)两者都算 -
CONCAT('a', phone)：若phone是NULL，整个结果是NULL；若是''，结果是'a' -
IFNULL(phone, 'N/A')只对NULL生效，对''不触发替换 -
COALESCE(phone, 'N/A')同样只认NULL，''会被原样返回 - 排序时：
ORDER BY phone默认把NULL排最前（升序），''和其他字符串一起排
建表阶段就要决定用 NULL 还是 ''，后期很难干净切换
一旦上线，改字段含义成本很高，尤其涉及索引、应用逻辑、ETL 脚本时。
- 文本字段如
address、bio：用户明确留空 → 存''；字段根本不适用（如“配偶姓名”对单身用户）→ 存NULL - 数值字段如
age、score：几乎不该存''，因为类型不匹配；缺失就用NULL - 避免在同一个业务含义下混用：比如“未填电话”有的行存
NULL、有的存''，后续所有查询都要写两套条件 - 如果历史数据已混用，清洗时用
UPDATE ... SET phone = NULL WHERE phone = ''是常见做法，但得确认应用层能兼容这种变更
真正麻烦的不是语法记不住，而是业务语义模糊时随便选一个；等数据积压几百万行，再回头区分哪条是“用户填了空”、哪条是“系统没收到”，基本只能靠日志或业务上下文硬猜。
