MySQL中NULL值比较不能用=，因为NULL= NULL返回UNKNOWN而非TRUE，导致WHERE条件漏掉NULL行；应使用NULL安全运算符或(col1 = col2) OR (col1 IS NULL AND col2 IS NULL)。
MySQL中NULL值比较为什么不能用=
直接用=比较两个可能为NULL的字段，结果永远是UNKNOWN而非TRUE或FALSE，所以WHERE col1 = col2会漏掉所有含NULL的行。这是SQL三值逻辑决定的——NULL = NULL不返回1，而是NULL。
常见错误现象：
- 表里有name和backup_name都为NULL的记录，但SELECT * FROM t WHERE name = backup_name查不到；
- UPDATE t SET flag=1 WHERE a = b没更新任何行，即使a、b列全为NULL。
解决思路：必须显式处理NULL语义，不能依赖常规等号。
用
是MySQL原生的NULL安全比较运算符，它把NULL当作一个确定的值来比：当两边同为NULL时返回1，一NULL一非NULL返回0，两个非NULL值则按常规相等判断。
实操建议：
-
WHERE col1 col2可直接替代=，且无需额外IS NULL判断 - 支持所有数据类型（包括
JSON、TEXT等），比IS NULL组合写法更简洁 - 在
ORDER BY、GROUP BY中不适用，它只用于布尔表达式上下文（如WHERE、HAVING、ON） - 注意：
不是标准SQL，仅MySQL和少数衍生库（如MariaDB）支持，跨数据库迁移需重写
示例：
SELECT * FROM users WHERE email <=> backup_email;
这条语句能正确命中
email和backup_email同时为NULL的记录，也能匹配两者都为'a@b.com'的记录。
兼容标准SQL的写法：用IS NOT DISTINCT FROM？
MySQL **8.0.22起才支持**IS NOT DISTINCT FROM（标准SQL的NULL安全等价语法），旧版本直接报错ERROR 1064。
如果你必须兼容老版本MySQL或PostgreSQL/Oracle等，稳妥做法仍是手写逻辑：
- 用
(col1 = col2) OR (col1 IS NULL AND col2 IS NULL)—— 注意括号不能省，否则优先级出错 - 若字段可能为
''空字符串，还要考虑是否视其等价于NULL，此时需额外TRIM()或NULLIF() - 性能上，
通常比OR组合更快，因为优化器能更好识别其语义并利用索引（尤其在WHERE中）
示例（兼容写法）：
SELECT * FROM t WHERE (a = b) OR (a IS NULL AND b IS NULL);
容易被忽略的边界情况
NULL安全比较不是万能的，这几个点实际开发中常踩坑：
-
对NaN（浮点数）行为未定义，MySQL中NaN NaN返回0而非1，需单独用IS_NAN()判断 - 字符集与排序规则影响结果：若两列字符集不同（如
utf8mb4vslatin1），仍会隐式转换，但可能触发警告甚至截断 - 在
ON子句中使用做JOIN条件时，如果被驱动表字段为NULL，可能导致意外的笛卡尔积放大（因NULL匹配所有NULL） -
JSON列用比较时，要求结构完全一致（键序、空格、数值精度），JSON_CONTAINS()或JSON_EXTRACT()更适合模糊匹配
真正要用好，得先看清字段的数据质量、业务语义是否允许NULL相等——有时候，把NULL统一转成默认值（如COALESCE(col, '')）反而更可控。
