explain中key为null仅表示优化器未选择索引，并非绝对失效；根本原因是成本估算认为全表扫描更优，尤其is null查询受null占比、联合索引最左前缀规则及统计准确性影响。
EXPLAIN 显示 key 为 NULL 就代表索引失效？
不一定。EXPLAIN 中 key 为 NULL 只说明优化器没选这个索引，不等于“不能走”。InnoDB 对 IS NULL 的支持在 MySQL 5.7+ 已明显增强，尤其是单列二级索引；但是否真走，取决于成本估算——如果表里 NULL 占比高（比如超 20%），优化器算下来全表扫描反而更快，就会跳过索引。
常见错误现象：EXPLAIN SELECT * FROM t WHERE col IS NULL; 返回 type=ALL、key=NULL，但同一列的 = 'xxx' 却能走索引。这不是索引坏了，而是优化器基于统计信息做了“更省”的选择。
实操建议：
- 先查统计：运行
SHOW INDEX FROM t WHERE Key_name = 'idx_col';，确认Null列值为YES（即该列允许 NULL） - 再强制验证：加
FORCE INDEX看效果：EXPLAIN SELECT * FROM t FORCE INDEX (idx_col) WHERE col IS NULL;，对比rows是否显著下降 - 更新统计：执行
ANALYZE TABLE t;，避免因旧统计误导优化器
联合索引中 IS NULL 为什么让整个索引“断掉”？
因为 InnoDB 的最左前缀匹配规则对 NULL 更敏感。联合索引 (a, b) 要求查询条件从左开始连续提供非空可比较值；一旦 a IS NULL，B+ 树就无法定位起始位置——NULL 不参与排序，也不写入键值序列，它被特殊放在叶子页最左或单独管理，导致后续列 b 的有序性无法利用。
典型失效场景：
-
WHERE a IS NULL AND b = 1→ 不走(a,b)索引 -
WHERE a = 1 AND b IS NULL→ 可走，a=1定位子树后，b IS NULL在该子树内线性扫描 -
WHERE a IS NULL OR b = 1→ 基本不走，OR+IS NULL双重打击
这不是 bug，是 B+ 树设计决定的：索引本质依赖有序性，而 NULL 天然无序。
UNIQUE 索引上 IS NULL 查询为什么特别难优化？
因为 UNIQUE 约束允许无限多个 NULL（标准 SQL 行为），这和“唯一性”语义冲突——优化器无法假设 IS NULL 结果集很小，也就没法把它当高效等值查找来处理。即使你只有一行 NULL，优化器仍按“可能有成百上千个”的悲观估计做成本计算。
结果就是：哪怕建了 UNIQUE(col)，WHERE col IS NULL 也大概率回退到全表扫描。
实操建议：
- 业务上真需要频繁查
IS NULL，优先考虑改字段为NOT NULL DEFAULT 'N/A'或0，彻底规避问题 - 若必须保留 NULL，且查询高频，可用覆盖索引绕过：比如常查
id和col，就建INDEX(col, id)，减少回表开销 - MySQL 8.0.13+ 可试函数索引：
CREATE INDEX idx_col_notnull ON t ((COALESCE(col, -1)));，但需业务层统一用-1替代 NULL 查询
IS NULL 走索引但查询仍慢，问题出在哪？
走了索引 ≠ 性能好。常见瓶颈在回表——IS NULL 走索引只能拿到主键，如果 SELECT * 或要取大量非索引列，就得一次次回聚簇索引捞数据，IO 成倍增加。
另一个容易被忽略的点：NULL 值分布不均。比如某列 99% 是 NULL，只有几行非 NULL，优化器可能误判 IS NULL 是“窄查询”，实际却要扫海量 NULL 记录（B+ 树里它们挤在一起，但每条都要检查并返回）。
实操建议：
- 用
SELECT COUNT(*) FROM t WHERE col IS NULL;看真实 NULL 行数，别信预估 - 避免
SELECT *，只取必要字段；能覆盖索引就建覆盖索引 - 如果 NULL 比例极高，且业务允许，直接删掉该列或归档 NULL 数据，比调优索引更有效
真正卡住的往往不是“能不能走索引”，而是“走完之后还要干多少事”。NULL 值让这个链条变得更不可控——它既影响索引结构，又干扰统计，还拖慢回表，三重叠加下，光看 EXPLAIN 的 key 字段远远不够。
