应使用 is null 而非 = null，因 null 是缺失标记而非值，= null 永不匹配；正确语法仅 column is null 或 is not null，且索引默认不包含 null，需特殊处理。
用 IS NULL 而不是 = NULL
MySQL 中 NULL 不是值，而是“缺失值”的标记，所以不能用等号比较。写 WHERE column = NULL 永远返回空结果——它不报错，但逻辑上永远为假。
正确写法只有两种：column IS NULL 或 column IS NOT NULL。这是 SQL 标准，所有主流数据库都一样。
-
= NULL、NULL、!= NULL全部无效，别试 - 哪怕字段类型是
INT、VARCHAR还是JSON，规则都不变 - 如果用了 ORM（比如 Laravel 的 Eloquent 或 Django ORM），也要确认它生成的是
IS NULL，而不是拼出= ?并把NULL当参数传进去
索引对 IS NULL 查询是否有效？
普通 B+ 树索引默认不存储 NULL 值（InnoDB 引擎下），所以 WHERE column IS NULL 通常走不了索引——除非你显式允许 NULL 进入索引。
解决办法有两个：
- 建索引时加
INCLUDE（MySQL 8.0+ 支持函数索引）：比如CREATE INDEX idx_col_null ON t ((col IS NULL))，但更常用的是下面这个 - 改字段为
NOT NULL并设默认值（如0、''、'unknown'），让业务逻辑接管“缺失”语义——这比查NULL更快也更可控 - 如果必须保留
NULL且高频查询，考虑冗余一个布尔字段col_is_null TINYINT(1)，配合触发器或应用层同步更新，然后给它建索引
小心 NULL 在聚合和连接中的“传染性”
NULL 参与计算或比较时，多数表达式会直接返回 NULL，容易导致查不到数据却没报错。比如：
SELECT * FROM orders WHERE status != 'shipped';
这条语句不会返回 status 为 NULL 的订单——因为 NULL != 'shipped' 结果是 UNKNOWN，被 WHERE 过滤掉。想包含 NULL，得显式写：
SELECT * FROM orders WHERE status != 'shipped' OR status IS NULL;
-
COUNT(column)自动忽略NULL；COUNT(*)统计所有行 -
LEFT JOIN右表无匹配时，右表字段全为NULL，后续条件里漏掉IS NULL判断，就会意外丢数据 -
COALESCE(col, 'default')或IFNULL(col, 'default')是安全兜底手段，但别滥用——掩盖问题不如厘清业务语义
从应用层传参时怎么处理 NULL？
很多客户端（如 Python 的 mysql-connector、Node.js 的 mysql2）支持直接绑定 NULL 参数，但注意：它们只是帮你拼成 IS NULL 或 = ?，后者依然无效。
- 用预处理语句时，
WHERE col = ?+ 绑定NULL→ 实际执行还是= NULL→ 查不到数据 - 正确做法：动态拼 SQL（不推荐）或用两个分支：
if value is None: ... IS NULL/else: ... = ? - 某些 ORM（如 SQLAlchemy）提供
is_(None)方法，生成的就是IS NULL，优先用这类语义化 API
实际写查询时，最常被忽略的不是语法，而是“这个字段到底该不该为 NULL”。定义表结构时多花两分钟想清楚业务含义，比后期反复修 IS NULL 条件要省事得多。
