IS NULL 查询不走索引，因InnoDB的B+Tree不存储NULL值，而是将其挂入叶子节点末尾的无序链表；优化器无法二分查找，常退化为全表扫描；改NOT NULL DEFAULT可根治，但日志字段、历史大表、唯一索引等场景需谨慎。
不是“赋NULL值”导致索引失效，而是查询中写 WHERE col IS NULL 时，MySQL 的 B+Tree 索引结构本身不支持高效定位 NULL —— 它压根没把 NULL 当成可比较的值来组织。
为什么 IS NULL 几乎不走索引
MySQL 的 InnoDB 不在 B+Tree 键值路径里存储 NULL，而是把所有 col IS NULL 的记录单独挂到叶子节点末尾的一个无序链表（NULL slot list）里。这意味着：
-
EXPLAIN看到type: ALL或key: NULL是正常现象，不是配置错误 - 优化器无法用二分查找跳转，只能顺序遍历这个链表，再回表取数据
- 如果 NULL 占比超过约 20%，优化器大概率直接放弃链表遍历，改全表扫描（成本更低）
- 哪怕你建了
INDEX(col)，WHERE col IS NULL依然不会触发常规索引扫描
NOT NULL DEFAULT 是根治手段，不是权宜之计
把字段改成 NOT NULL 并设默认值（如 0、''），能从源头消除 IS NULL 查询需求，让所有等值和范围查询回归稳定走索引：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 执行
ALTER TABLE t MODIFY col INT NOT NULL DEFAULT 0;前，先查存量：SELECT COUNT(*) FROM t WHERE col IS NULL;，非零就得清洗 - 字符串字段慎用
DEFAULT ''，得确认业务是否接受空字符串语义（比如邮箱为空 vs 未提供） - 改完后，原
WHERE col IS NULL要同步改成WHERE col = 0，应用层 ORM 也要检查 nullability 配置（如 Java 的Integervsint） - 联合索引中某列改
NOT NULL后，key_len会减小 1 字节，索引页密度提升，B+Tree 层数可能下降
哪些情况不该硬上 NOT NULL
不是所有字段都适合一刀切，以下场景强行改会引入更大问题：
- 日志类字段（如
processed_at）：天然大量未处理状态，设DEFAULT '1970-01-01'会污染时间语义，更适合加生成列 + 索引 - 历史大表且不能停机：改表结构耗时长、锁表久，可先在应用层拦截
INSERT时补默认值，并把查询IS NULL改写为= 'placeholder' - 唯一索引依赖 NULL 多值特性（如
UNIQUE(email)允许多行 email 为 NULL）：设NOT NULL会破坏约束逻辑，应拆物理列或由应用保证去重
真正容易被忽略的是：即使你建了联合索引 (a, b)，WHERE a = 1 AND b IS NULL 能走索引，但 WHERE a IS NULL AND b = 1 就不行——因为最左列 a IS NULL 无法划定子树边界，整个索引都得扫。这种“半失效”在复合条件里极难排查，必须靠 EXPLAIN 看 key_len 和 rows 才能确认。
