必须用is null判断null，因为null是未知状态而非值，= null返回unknown被where过滤；正确写法为where column is null，跨数据库通用且语义明确。
因为NULL不是值，而是“未知”状态，= 运算符无法对未知状态返回 TRUE 或 FALSE，只会得到 UNKNOWN —— 而 WHERE 只保留 TRUE 的行。
WHERE column = NULL 为什么查不到数据
这是最常踩的坑：你执行 SELECT * FROM users WHERE email = NULL，哪怕表里真有 email 是 NULL 的记录，结果也一定是空的。
-
= NULL不是语法错误，但语义上永远不成立：SQL 标准规定，任何值（包括 NULL 自身）与 NULL 做等号比较，结果都是UNKNOWN -
WHERE子句只保留条件计算结果为TRUE的行；FALSE和UNKNOWN都被过滤掉 - 同理，
email != 'test@example.com'也会漏掉email为 NULL 的行，因为NULL != 'test@example.com'也是UNKNOWN
IS NULL 是谓词，不是函数，也不是语法糖
IS NULL 和 IS NOT NULL 是 SQL 标准定义的专用谓词（predicate），它不参与比较运算，只做存在性判断。
- ✅ 正确：
WHERE updated_at IS NULL、WHERE name IS NOT NULL - ❌ 错误：
WHERE updated_at = IS NULL（多写了=）、WHERE IS NULL(updated_at)（误当函数调用）、WHERE email IN (NULL)（整条条件变UNKNOWN） - 它不触发隐式类型转换，跨数据库行为稳定：MySQL、PostgreSQL、SQL Server、Oracle 全部一致支持
NOT IN 遇到 NULL 会静默失效
子查询或字面量列表中只要含一个 NULL，整个 NOT IN 表达式就变成 UNKNOWN，导致本该命中的行全部丢失。
- 例如：
SELECT * FROM orders WHERE status NOT IN (SELECT code FROM status_ref)，若status_ref.code中有 NULL，则所有订单都被过滤 - 修复方式不是加
OR status IS NULL，而是显式排除：SELECT code FROM status_ref WHERE code IS NOT NULL - 更健壮的替代方案是用
NOT EXISTS，它天然绕过 NULL 比较陷阱
IS NULL 的性能和索引表现差异很大
能不能走索引，不能一概而论，必须看数据库引擎和索引类型。
- MySQL 的普通 B+Tree 索引默认不存储 NULL，
WHERE col IS NULL很可能触发全表扫描 - PostgreSQL 的 B-tree 索引默认包含 NULL，
IS NULL和IS NOT NULL都能高效使用索引 - 执行前务必用
EXPLAIN看执行计划：关注是否有Index Scan或Index Only Scan；没有的话，考虑加覆盖索引或改用物化视图
真正容易被忽略的是：NULL 不仅影响 WHERE，还会渗透到 JOIN 条件、聚合函数、标量子查询和排序逻辑中。比如 COUNT(email) 会跳过 NULL 行，而 COUNT(*) 不会；LEFT JOIN 后用 ON a.id = b.a_id 匹配时，若 b.a_id 是 NULL，整个关联条件就是 UNKNOWN —— 这些都不是“写错了”，而是 NULL 的语义在起作用。
