Most database indexes types do not index NULL values. What this means is that anywhere a query’s WHERE clause contains “IS NULL” a full table scan will ensue (or at best an index range scan).
This stems from the fact that a NULL assignment in database terms actually means that no value has been assigned.
As I’ve mentioned before cardinality plays a large part in the efficiency of an index. I also think database implementers have considered indexing NULL values will lead to poorly performing indexes, because of the effect of on the field’s cardinality.
I have outlined below some possible solutions to performance issues associated with searching for NULL values.
My first suggestion is to consider querying on a different field altogether. Recently, I had to modify a query searching for null values in a foreign key field, i.e. no foreign key reference. When I analysed the table’s usage, I discovered that a mutually exclusive relationship existed with another foreign key. In other words, I could check for null values in field A by making sure there were values assigned to field B. Thus, for a query, I replace “WHERE FKeyA IS NULL” with “WHERE FKeyB IS NOT NULL”, which is easily indexed.
Solution number two is not to use a NULL value at all but to assign some standard code value instead. Consider it similar to putting “NA” instead of NULL in a field. Crucially, this will affect the cardinality of any indexes indexing this field and hence affect their performance. If your table has fields to index where the NULL value is common, this approach will be a poor performer.
Technique three is an Oracle specific approach. Oracle supports an unusual index type called a Bitmapped index. This index is specifically designed to perform well for fields with low cardinality. Thus, for Bitmapped indexes, indexing NULL values makes a lot of sense. Bitmapped indexes are the only index type I know that actively indexes NULL values.
