= NULL 永远不成立，必须用 IS NULL 判断空值；因 NULL 表示未知，任何与 NULL 的比较结果均为 UNKNOWN，在 WHERE 中被当作 FALSE 过滤。
MySQL 中 IS NULL 和 = NULL 的区别
直接说结论：= NULL 永远不成立，MySQL 里必须用 IS NULL 判断空值。这是 SQL 标准规定，不是 MySQL 特性——因为 NULL 表示“未知”，而任何与未知的比较（包括等于、不等于）结果都是 UNKNOWN，在 WHERE 条件中会被当作 FALSE 过滤掉。
常见错误现象：
- 写
WHERE column_name = NULL查不到任何数据，哪怕该列全是NULL - 用
!= NULL或NULL也查不到非空数据，得用IS NOT NULL
实操建议：
- 永远用
IS NULL/IS NOT NULL做空值判断 - 别依赖 IDE 或客户端的自动补全，有些会错误提示
= NULL语法合法（它确实“语法合法”，但逻辑无效） - 如果用 ORM（如 Django、MyBatis），注意它们生成的 SQL 是否正确转义了空值条件
联合索引下 IS NULL 能否走索引
能，但有前提：索引字段必须允许 NULL，且查询条件是 IS NULL（不是 IS NOT NULL），并且该字段在联合索引中处于“可被利用的位置”。
使用场景：
- 表有联合索引
(a, b, c)，执行SELECT * FROM t WHERE a = 1 AND b IS NULL—— 可以用上索引前两列 - 但
WHERE b IS NULL单独查询，无法使用该联合索引（最左前缀失效）
容易踩的坑：
-
IS NOT NULL在大多数 MySQL 版本中（5.7/8.0）对 B+Tree 索引基本不走范围扫描，实际执行计划常显示type: ALL或index - 如果字段定义为
NOT NULL，那IS NULL条件永远返回空结果，优化器可能直接跳过扫描 - 建索引时没留意字段是否允许
NULL，会导致明明写了IS NULL却用不上索引
字符串字段存空字符串 '' 和 NULL 怎么区分查
这是高频混淆点：''（空字符串）和 NULL 是完全不同的值，IS NULL 查不到 ''，= '' 也查不到 NULL。
常见错误现象：
- 用户注册时没填手机号，后端存了
''，但查询“未填写手机号”时只写phone IS NULL，漏掉这批数据 - 导出报表时把
NULL和''都当“空”处理，结果统计口径错乱
实操建议：
- 明确业务语义：字段设计阶段就决定是用
NULL（表示“无意义/未采集”）还是''（表示“明确为空”） - 查询时按需组合：
WHERE phone IS NULL OR phone = '' - 避免在同一个字段混用两种“空”，否则后续清洗和判断成本陡增
JSON 字段里怎么查某个 key 是否为 NULL
MySQL 5.7+ 的 JSON 类型字段，不能直接用 col->'$.key' IS NULL 判断 key 不存在或值为 NULL，因为 -> 操作符遇到缺失 key 会返回 NULL，和 key 存在但值为 NULL 无法区分。
正确做法是用 JSON_CONTAINS_PATH() 先确认 key 是否存在：
SELECT * FROM t WHERE JSON_CONTAINS_PATH(data, 'one', '$.status') AND data->>'$.status' IS NULL;
性能影响：
-
JSON_CONTAINS_PATH()在大数据量下性能一般，尤其嵌套深、路径多时 - 如果频繁按某个 JSON key 查询，建议抽成生成列（generated column）并加索引，例如：
ALTER TABLE t ADD status VARCHAR(20) AS (data->>'$.status');
容易被忽略的是：JSON 解析本身有开销，IS NULL 判断前先做路径检查，这步绕不开。如果业务上“key 不存在”和“key 值为 NULL”要同等对待，那就直接用 COALESCE(data->>'$.status', '') = '' 更直白，虽然牺牲一点语义精度。
