如果可以避免将列保持为NULL,这总是一个很好的理想,因为使用的语义非常混乱;请参阅
What is the deal with NULLs?,了解这些如何让您陷入困境.
在高达8.2的Postgresql版本中,该软件不知道如何在最常见的类型索引(b-tree)上进行比较,其方式包括在其中查找NULL值.在documentation on index types的相关位中,您可以看到描述为“但请注意,IS NULL不等于=且不可索引”.这样做的有效缺点是,如果您指定一个需要包含NULL值的查询,那么计划程序可能无法使用该情况的明显索引来满足它.举个简单的例子,如果你有一个可以用索引加速的ORDER BY语句,但你的查询也需要返回NULL值,那么优化器就不能使用那个索引,因为结果将丢失任何NULL数据 – 和因此是不完整和无用的.优化器知道这一点,而是将对表进行无索引扫描,这可能非常昂贵.
Postgresql improved this in 8.3,“索引列上的IS NULL条件可以与B树索引一起使用”.因此,通过尝试使用NULL值索引某些内容可能会导致烧毁的情况已经减少.但是由于NULL语义仍然非常痛苦,并且你可能会遇到这样一种情况,即使8.3计划程序因为它们而没有按照你的意愿行事,你仍然应该尽可能使用NOT NULL来降低遇到严重优化查询的机会.