MySQL中IS NULL查询能否利用索引，取决于索引类型、字段是否允许NULL、MySQL版本及存储引擎；在InnoDB中，NULL值不参与B+树排序，当NULL值比例较高时，优化器可能放弃使用索引。自MySQL 5.7版本后，对IS NULL查询的索引支持有所增强，但联合索引中若最左前缀列为NULL，则索引匹配会中断。此外，UNIQUE索引因允许多个NULL值共存，通常难以优化IS NULL查询。
关于MySQL中IS NULL查询能否走索引，一个普遍的误区是认为它总会“失效”。实际上，情况更为复杂：这取决于索引类型、字段是否允许为NULL，以及MySQL版本和存储引擎（尤其是InnoDB）。虽然不能一概而论，但其中确实存在许多容易踩中的性能陷阱。
为什么 IS NULL 查询有时无法使用索引
根本原因在于InnoDB存储引擎对NULL值的特殊处理机制。在B+树索引结构中，NULL值不参与常规的排序比较，也不会像普通值那样被规整地组织在索引页的有序序列中。这就导致了一个核心问题：对于允许为空的单列索引，当查询条件为IS NULL时，MySQL优化器可能会评估认为，使用索引扫描的成本反而高于直接进行全表扫描——尤其是在表中NULL值占比很高的情况下。
一个典型的性能问题表现是：使用EXPLAIN分析查询执行计划时，明明该字段已建立索引，但结果却显示type=ALL（全表扫描）或key=NULL（未使用任何索引）。
- 当然，并非所有
IS NULL查询都会放弃索引。从MySQL 5.7版本开始，特别是8.0之后，InnoDB对IS NULL查询的索引支持已经有了显著优化，单列二级索引的情况改善尤为明显。 - 联合索引的情况则更为复杂。如果查询条件中，联合索引的最左前缀列是
NULL，那么整个索引匹配就会在此中断。例如，对于索引INDEX(a,b)，查询WHERE a IS NULL AND b = 1是无法有效利用这个联合索引的。 UNIQUE唯一索引对NULL的处理则更为特殊：SQL标准规定，多个NULL值并不违反唯一性约束。这个特性本身合理，但它也直接导致了优化器很难利用唯一索引来加速IS NULL查询。
如何判断 IS NULL 查询能否走索引：实操方法
面对不确定性，最佳方法不是猜测，而是通过实证分析。直接使用EXPLAIN配合SHOW INDEX命令进行验证，重点关注以下三个关键点：
- 首先，执行
SHOW INDEX FROM table_name WHERE Key_name = 'your_index';，确认目标列的Null属性是否为YES。这直接说明了该列是否允许存储NULL值。 - 接着，运行你的
IS NULL查询并加上EXPLAIN前缀：EXPLAIN SELECT * FROM table_name WHERE column_name IS NULL;。观察结果中的key字段是否非空，以及rows字段的估算行数是否显著小于表的总行数。 - 如果怀疑优化器选错了索引，可以尝试强制使用索引进行对比：
EXPLAIN SELECT * FROM table_name FORCE INDEX (idx_col) WHERE column_name IS NULL;。查看强制走索引后，估算的rows是否大幅下降，这有助于判断优化器的成本估算是否准确。
另外，MySQL 8.0.13及以上版本对函数索引的支持更加完善。理论上，你可以通过创建如COALESCE(column_name, 'NULL_MARKER')这样的函数索引来规避原生NULL带来的索引问题。但这种方法需要业务层严格配合，统一“空值标记”的逻辑，实施起来有一定复杂度。
真正有效的解决方案（按优先级排序）
发现问题后，不要急于堆砌索引或改动表结构。更合理的做法是，按照以下优先级，尝试从源头解决问题：
- 将字段设为
NOT NULL并赋予默认值：如果业务逻辑允许，这是最彻底、最优雅的解决方案。执行一句ALTER TABLE t MODIFY col INT NOT NULL DEFAULT 0;，从此IS NULL查询失去了存在的土壤，索引自然可以高效工作。 - 利用覆盖索引减少回表开销：有时候，即使
IS NULL走了索引，如果SELECT的字段不能完全从索引中获取，就需要回表查询主键，性能损耗依然很大。这时，可以考虑建立包含所需查询字段的覆盖索引，例如INDEX(col, other_col)，让查询所需数据能直接从索引中拿到。 - 避免在高频查询字段上存储大量
NULL：这是数据库设计层面的优化。例如，用一个具体的数值（如0或-1）来代替NULL表示“未知”或“未设置”状态。这不仅能提升索引效率，也能简化应用层繁琐的判空逻辑。 - 最后，不到万不得已，不要轻易依赖
COALESCE函数索引。它虽然能解决问题，但会引入额外的函数计算开销，影响写入性能。更麻烦的是，它要求应用层必须始终保持一致的“空值标记”逻辑，任何一个边缘案例的遗漏都可能引发数据不一致。
联合唯一索引中包含 NULL 值的特殊陷阱
这是最隐蔽、也最容易引发困惑的复杂场景。MySQL有一个独特的规定：在UNIQUE约束下，只要联合索引中的任意一列是NULL，那么这整行数据就不参与唯一性校验。换句话说，(1, NULL)和另一个(1, NULL)是可以同时存在的，它们不被视为重复。
这个特性带来的直接后果就是：
- 像
SELECT ... WHERE a = 1 AND b IS NULL这样的查询，几乎注定要走全表扫描。因为优化器清楚地知道，b IS NULL所匹配的那些行，在索引里是分散且无法精确定位的。 - 即便你为
(a,b)两列创建了UNIQUE索引，它也完全无法加速涉及IS NULL的查询。这个索引的存在，反而可能给你一种“查询已被索引覆盖”的安全假象。 - 修复这个陷阱，通常只有两个方向：要么彻底将相关字段改为
NOT NULL并设置默认值；要么进行架构调整，例如将包含可空关系的业务拆解到单独的关联表中进行隔离处理。
说到底，最危险的往往不是“索引失效”这个结果本身，而是失效过程的不透明性——执行计划可能依然显示使用了某个索引，但实际需要扫描的行数rows却接近全表。这种悄无声息的性能退化，往往要到慢查询日志告警时才会被发现，届时可能已对系统造成了实际影响。
