必须用IS NULL或IS NOT NULL判断NULL，因NULL是“未知”状态而非值，= NULL或!= NULL永远返回UNKNOWN（视为FALSE），查不到结果；WHERE col = NULL错误，WHERE col IS NULL正确。
IS NULL不能用等号判断，必须用专门操作符
SQL里空值NULL不是值，而是“未知”状态，所以= NULL或!= NULL永远返回FALSE或UNKNOWN，查不到任何结果。必须用IS NULL或IS NOT NULL——这是唯一可靠方式。
常见错误是写成：WHERE column_name = NULL，这在所有主流数据库（MySQL、PostgreSQL、SQL Server）里都无效。
-
WHERE column_name IS NULL→ 正确匹配该列为NULL的行 -
WHERE column_name IS NOT NULL→ 排除NULL，但注意：它也排除''（空字符串）和0（数字零），因为它们是真实值 - 如果想同时查
NULL和空字符串，得显式写：WHERE column_name IS NULL OR column_name = ''
不同数据库对空字符串和NULL的处理差异
MySQL默认开启STRICT_TRANS_TABLES时，插入空字符串不会自动转成NULL；而某些ORM（如Django）或应用层可能把空表单提交为NULL，导致数据不一致。查的时候容易漏掉一类“看似为空实为''”的数据。
PostgreSQL更严格，''和NULL完全分离；SQL Server中ANSI_NULLS若被关闭（不推荐），= NULL可能意外生效，但这是兼容性陷阱，应禁用。
- 安全做法：始终分开判断，例如查用户邮箱缺失：
WHERE email IS NULL OR email = '' - 建表时明确约束：
email VARCHAR(255) NOT NULL可避免NULL，但需业务允许强制填写 - 索引对
NULL的支持因引擎而异：MySQL的B+树索引默认跳过NULL，除非用IS NULL条件且字段有索引
IS NULL在JOIN和子查询里的行为容易误判
LEFT JOIN右边表的字段若为NULL，是因为没匹配上，不是数据本身为空——这时候用IS NULL是合理的过滤手段；但若在WHERE里对左表字段写IS NULL，可能意外过滤掉本应保留的行。
典型陷阱：SELECT * FROM orders LEFT JOIN users ON orders.user_id = users.id WHERE users.name IS NULL，这会只返回“无用户信息的订单”，但如果想查“用户姓名字段存了NULL的订单”，就得确认users.name真被设为NULL，而非JOIN失败。
- 多表关联时，先确认
NULL来源：是JOIN未命中？还是原始数据就是NULL？ - 子查询中
IN (subquery)遇到NULL会整体返回UNKNOWN，导致无结果；改用EXISTS更稳妥 -
COUNT(column_name)自动忽略NULL，但COUNT(*)统计所有行——这点常被用来快速估算空值比例
ORDER BY里NULL默认排前面还是后面取决于数据库
MySQL默认把NULL排在最前（ASC时），PostgreSQL默认排最后，SQL Server则按设置浮动。如果业务要求“空值放末尾”，不能只靠ORDER BY column_name ASC，得显式控制。
- 标准写法（通用）：
ORDER BY column_name IS NULL, column_name ASC—— 把IS NULL当布尔表达式参与排序，FALSE（即非空）排前面 - MySQL特有：
ORDER BY column_name ASC NULLS LAST（8.0.13+支持），但兼容性差，不建议依赖 - 如果字段类型混用（比如
VARCHAR和INT），NULL比较仍遵循同一规则，但排序结果可能因类型隐式转换而意外偏移
真正麻烦的不是语法，是分不清“没填”“填了空字符串”“填了0”“数据库写入失败导致NULL”——查之前，先翻表结构和业务逻辑，比死记IS NULL有用得多。
