MySQL中NULL值在WHERE条件中常无法走索引，因其是缺失值标记而非真实值，IS NULL/IS NOT NULL绕过B+树有序比较逻辑；联合索引中前导列为NULL时破坏键值拼接结构，导致后续列失效；高频IS NULL查询应建单列索引，避免中间列允许NULL，并用EXPLAIN验证实际索引使用效果。
MySQL 的 NULL 值在 WHERE 条件中为什么走不了索引？
因为 NULL 在 MySQL 中不是值，而是“缺失值”的标记，所有涉及 IS NULL 或 IS NOT NULL 的判断都绕过常规的 B+ 树比较逻辑。B+ 树节点内部做的是「有序比较」（如 a ），而 NULL = NULL 为 UNKNOWN，无法参与大小排序，所以普通索引列上 WHERE col = NULL 永远不命中索引（实际会全表扫描）。
实操建议：
- 想让
NULL走索引，必须显式写成WHERE col IS NULL，且该列需有单列索引或联合索引的最左前缀位置 - 如果建的是
UNIQUE索引，MySQL 允许多个NULL（标准 SQL 要求如此），但底层 B+ 树里这些NULL并不存于键值排序序列中，而是被单独挂到叶子节点末尾的“空值链表”里 - 联合索引如
(a, b)，若查询WHERE a = 1 AND b IS NULL，可以走索引；但WHERE a IS NULL AND b = 1就不行——因为a是最左列，IS NULL不提供范围边界，优化器无法定位子树
B+ 树叶子节点里，NULL 到底存哪儿了？
MySQL 的 InnoDB 存储引擎对 NULL 做了特殊处理：每个记录的行格式（如 COMPACT）会在头信息里设一个 NULL bitmap，标记哪些列为 NULL；而 B+ 树索引页中的键值（index key）本身**不存储 NULL 字面量**。当某索引列值为 NULL 时，InnoDB 会把整条索引记录的键值部分设为“空”，并在叶子页内用一个独立的、按插入顺序维护的 NULL slot list 链表来指向这些记录。
这意味着：
-
SELECT * FROM t WHERE c IS NULL查的是这个链表，不是二分查找 B+ 树路径 - 该链表不排序，所以
ORDER BY c配合IS NULL无法利用索引排序 - 如果表里
NULL占比极高（比如 > 20%），优化器可能直接放弃走索引，改用全表扫描——因为它发现遍历链表 + 回表的成本高于扫聚簇索引
联合索引中 NULL 对最左匹配原则的影响
联合索引的本质是按字段顺序拼接键值排序，一旦某个前导列是 NULL，就破坏了这个拼接结构。例如索引 (a, b, c)，记录 (1, NULL, 5) 的索引键实际存为 (1, NULL)（c 不参与索引键构造），而 (NULL, 2, 3) 的索引键根本不会进入正常排序路径，只进 NULL slot list。
所以：
-
WHERE a = 1 AND b IS NULL→ 可走索引，a定位子树，b IS NULL在子树内遍历 NULL 链表 -
WHERE a IS NULL AND b = 2→ 不走索引，因为a IS NULL无法缩小搜索范围，整个索引树都要查 -
WHERE a > 0 AND b IS NULL→ 仍可走索引，a > 0给出范围起点，再在匹配的叶子页中查b的 NULL 链表
建索引前要不要把 NULL 改成默认值？
不能一概而论。把 NULL 强制改成 0 或 '' 看似“规避问题”，但会扭曲语义：0 是有效数值，NULL 是未知/不适用。业务上真需要区分“未填写”和“填了零”，就不能替换。
更务实的做法是：
- 高频查询
IS NULL的列，单独建单列索引（哪怕只是INDEX (c)），确保它能走NULL slot list - 避免在联合索引中间列允许
NULL，尤其当该列常用于IS NULL查询——它会让后续列完全失效 - 用
EXPLAIN FORMAT=TRADITIONAL看key_len和rows，确认IS NULL是否真的走了索引；有时候看起来走了，其实key_len为 0，说明只是用了索引结构但没做有效过滤
真正容易被忽略的是：InnoDB 的 NULL slot list 不持久化到磁盘索引页的有序区，每次从缓冲池读取叶子页后才动态构建。这意味着高并发下大量 IS NULL 查询可能加剧页内锁竞争，而不是你想象的“轻量查找”。
