数据库里存着成千上万条数据，查起来本来就不轻松。有时候写SQL，顺手加上一个 WHERE column = NULL 或者 IS NULL 的条件，结果发现查询变慢了，心里就开始嘀咕：是不是这个“null值判断”拖了后腿？
null值本身不是性能杀手
null在数据库里代表“未知”或“无值”，它和0、空字符串都不一样。单纯判断某个字段是不是null，并不会直接让查询变慢。真正影响速度的，是你的表结构和索引设计。
比如你有一张用户表，里面有个 last_login 字段记录最后一次登录时间，很多新用户还没登录过，这个字段就是null。你想查所有没登录过的用户：
SELECT * FROM users WHERE last_login IS NULL;如果这张表有几百万条数据，但 last_login 没有加索引，那每次执行这条语句都得全表扫描一遍——不管你是查普通值还是null值，都会慢。
索引才决定快慢
给 last_login 加上索引之后，情况就不一样了。大多数主流数据库（如MySQL、PostgreSQL）的B+树索引是支持存储null值的，而且可以高效定位到这些记录。
你可以这样建索引：
CREATE INDEX idx_last_login ON users(last_login);建完之后再执行 IS NULL 查询，速度明显提升。因为数据库可以直接通过索引找到所有null值的位置，不用挨个翻数据行。
特殊情况要注意
有些场景下，null值确实会间接拖慢查询。比如你在复合索引中把可能为null的字段放在前面，而查询时又只用到了后面的字段，这时候索引可能无法充分利用。
另外，某些老版本数据库或特定存储引擎（比如MySQL的MyISAM）对null值的处理不太友好，也可能影响索引效率。但现在多数用InnoDB，基本不用担心这个问题。
别乱用函数包装
真正让查询变慢的，往往是这种写法：
SELECT * FROM users WHERE IFNULL(last_login, '1970-01-01') = '1970-01-01';你在字段上套了个函数，数据库没法用索引了，只能逐行计算，速度自然下来了。想判断null，老老实实用 IS NULL 就行。
还有一个常见误区：以为 column = NULL 能查到数据。实际上这样写永远查不出东西，正确写法是 column IS NULL。语法错了，查不出来，还谈什么速度。
实际优化建议
如果你经常要根据某个可能为空的字段做筛选，最好提前规划好索引。比如运营常要看“未填写手机号的用户”，那就在 phone 字段上建索引。
也不用刻意避免使用null。合理使用null能更准确表达业务含义，比如“用户没填生日”和“用户填了0000-00-00”完全是两回事。关键是要清楚每张表的查询模式，按需建索引。
线上系统做过一次调整：原本查“未发货订单”用的是 WHERE delivery_time IS NULL，没加索引，查一次要三秒。后来给 delivery_time 加了索引，同一语句不到0.1秒就出结果了。变的不是null判断，而是有没有走索引。