数据库查询中，经常需要判断某个字段是否为 null。很多人担心加上 is null 或 is not null 会影响查询性能，尤其是在数据量大的时候。其实，这个影响有没有，得看具体情况。
索引和 null 值的关系
大多数数据库的 B-Tree 索引默认不存储全 null 的行。比如 MySQL 的普通索引，如果某列全是 null，那这一行可能就不会被纳入索引结构中。这就意味着，当你执行 where column is null 时，即使该列有索引，也可能无法走索引扫描，而是变成全表扫描。
举个例子，一张用户表 user_info 有几十万条数据，其中 status 字段表示用户状态，有些记录 status 是 null。如果没对 status 做特殊索引处理，执行下面这条语句：
SELECT * FROM user_info WHERE status IS NULL;很可能触发全表扫描，速度自然就慢了。但如果 status 字段建立了索引，并且数据库支持索引包含 null 值（比如 PostgreSQL 就可以），那查询效率会明显提升。
复合索引中的 null 判断
在复合索引中，null 的存在也可能导致索引失效。例如，有一个联合索引 (a, b, c)，如果你的查询条件是 where a = 1 and b is null，那么 c 的索引部分可能就用不上。因为 null 在排序和比较时具有不确定性，数据库优化器很难准确估算匹配行数，容易选择错误的执行计划。
实际场景：日志表中的空值处理
假设你在维护一个操作日志表，error_msg 字段记录错误信息，正常操作时为 null。你想查出所有出错的日志：
SELECT * FROM operation_log WHERE error_msg IS NOT NULL;如果 error_msg 上有索引，这个查询可以很快定位到非空行。但要是这个字段很少非空，或者根本没建索引，哪怕只查几百条数据，也可能拖慢整个系统响应。
避免 null 带来的性能问题
一个常见的优化方式是，用默认值代替 null。比如 status 字段，不用 null 表示“未设置”，而用 0 或 'unknown' 这样的明确值。这样既能保持语义清晰，又能确保索引有效。
另外，在设计表结构时，明确声明字段是否允许 null。不允许就设为 NOT NULL，减少后续查询的歧义。对于必须存 null 的场景，考虑使用函数索引或部分索引，比如 PostgreSQL 的：
CREATE INDEX idx_error_on_null ON operation_log ((error_msg IS NULL));这种索引专门针对 null 判断做优化，能显著提升特定查询的速度。
所以，null 值判断会不会拖慢查询，关键看有没有合理的索引支持，以及数据分布情况。不是所有 null 都慢，也不是所有判断都危险，重点是根据实际业务设计好结构和索引策略。