Jeg vil være kræsen for ordvalg et øjeblik:
- Selv om det var en væsentlig præstationsfaktor, gør det det ikke semantisk korrekt for at bruge en værdi i stedet for NULL. I SQL har NULL en semantisk rolle, for at angive en manglende eller uanvendelig værdi. Ydeevneegenskaberne for NULL i en given RDBMS-implementering er uafhængige af dette. Ydeevnen kan variere fra mærke til mærke eller fra version til version, men formålet med NULL på sproget er konsekvent.
Jeg har i hvert fald ikke hørt om beviser for, at NULL klarer sig dårligt. Jeg ville være interesseret i eventuelle referencer til præstationsmålinger, der viser, at nullbare kolonner klarer sig dårligere end ikke-nullable kolonner.
Jeg siger ikke, at jeg ikke tager fejl, eller at det ikke kan være sandt i nogle tilfælde - bare at det ikke er meningsfuldt at komme med tomme formodninger. Videnskaben består ikke af formodninger; man skal vise beviser med gentagelige målinger.
Metrics fortæller dig også efter hvor meget ydelsen er forskellig, så du kan vurdere, om det er noget, der er værd at bekymre sig om. Det vil sige, at virkningen kan være målbar og ikke-nul, men stadig ubetydelig sammenlignet med større ydeevnefaktorer, såsom korrekt indeksering af tabeller eller dimensionering af din databasecache.
I MySQL kan søgninger efter NULL drage fordel af et indeks:
mysql> CREATE TABLE foo (
i INT NOT NULL,
j INT DEFAULT NULL,
PRIMARY KEY (i),
UNIQUE KEY j_index (j)
);
mysql> INSERT INTO foo (i, j) VALUES
(1, 1), (2, 2), (3, NULL), (4, NULL), (5, 5);
mysql> EXPLAIN SELECT * FROM foo WHERE i = 3;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| 1 | SIMPLE | foo | const | PRIMARY | PRIMARY | 4 | const | 1 | |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
mysql> EXPLAIN SELECT * FROM foo WHERE j IS NULL;
+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+
| 1 | SIMPLE | foo | ref | j_index | j_index | 5 | const | 2 | Using where |
+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+
Bemærk, at det stadig ikke er en måling af ydeevne. Jeg har kun vist, at du kan bruge et indeks, mens du søger efter NULL. Jeg vil påstå (ganske vist uden at have målt, men hey, det er bare StackOverflow), at fordelen ved et indeks overskygger enhver mulig straf, når man søger efter NULL versus en tom streng.
Det er ikke en korrekt designbeslutning at vælge nul eller blank eller nogen anden værdi, der skal erstatte NULL. Du skal muligvis bruge disse værdier som signifikante i kolonnen. Det er derfor, NULL eksisterer, som en værdi, der per definition er uden for domænet af værdier af enhver datatype, så du kan bruge hele rækken af værdier af heltal eller strenge eller hvad som helst og stadig have noget at betegne "ingen af ovenstående værdier. "