一、性能

如果查詢中包含可為null的列，對MYSQL來說更難優(yōu)化，因為可為null的列使得索引、索引統(tǒng)計和值比較都更復雜?？蔀閚ull的列會使用更多的存儲空間，在MYSQL里也需要特殊處理。當可為null的列被索引時，每個索引記錄需要一個額外的字節(jié)，在MyISAM里甚至還可能導致固定大小的索引（例如只有一個整數(shù)列的索引）變成可變大小的索引。

通常把可為null的列改為not null帶來的性能提升比較小，所以（調優(yōu)時）沒有必要首先在現(xiàn)有schema中查找并修改掉這種情況，除非確定這會導致問題。但是，如果計劃在列上建索引，就應該盡量避免設計成可為null的列。

當然也有例外，例如值得一提的是，InnoDB使用單獨的位（bit）存儲null值，所以對于稀疏數(shù)據(jù)有很好的空間效率。但這一點不適用于MyISAM。

注意：稀疏數(shù)據(jù)指的是很多值為null，只有少數(shù)行的列有非null值的情況。

二、開發(fā)的友好性

可以減少對空值的額外處理邏輯，開發(fā)人員可以更加簡潔和清晰的編寫代碼。

三、聚合函數(shù)不準確

對于null值的列，使用聚合函數(shù)的時候會忽略null值。

現(xiàn)在我們有一張表，name字段默認是null，此時對name進行count得出的結果是1，這個是錯誤的。

count(*)是對表中的行數(shù)進行統(tǒng)計，count(name)則是對表中非null的列進行統(tǒng)計。

四、null與其它值計算

null和其他任何值進行運算都是null，包括表達式的值也是null。比如null+1等于null，concat()函數(shù)拼接也還是null。

五、distinct、group by、order by的問題

對于distinct和group by來說，所有的null值都會被視為相等，對于order by來說升序null會排在最前。

六、索引問題

為了驗證null字段對索引的影響，分別對name和age添加索引。

關于網(wǎng)上很多說如果null那么不能使用索引的說法，這個描述其實并不準確，根據(jù)引用官方文檔[3]里描述，使用is null和范圍查詢都是可以和正常一樣使用索引的，實際驗證的結果好像也是這樣，看以下例子。 

然后接著我們往數(shù)據(jù)庫中繼續(xù)插入一些數(shù)據(jù)進行測試，當null列值變多之后發(fā)現(xiàn)索引失效了。 

我們知道，一個查詢SQL執(zhí)行大概是這樣的流程：

首先連接器負責連接到指定的數(shù)據(jù)庫上，接著看看查詢緩存中是否有這條語句，如果有就直接返回結果。

如果緩存沒有命中的話，就需要分析器來對SQL語句進行語法和詞法分析，判斷SQL語句是否合法。

現(xiàn)在來到優(yōu)化器，就會選擇使用什么索引比較合理，SQL語句具體怎么執(zhí)行的方案就確定下來了。

最后執(zhí)行器負責執(zhí)行語句、有無權限進行查詢，返回執(zhí)行結果。

從上面的簡單測試結果其實可以看到，索引列存在null就會導致優(yōu)化器在做索引選擇的時候更復雜，更加難以優(yōu)化。

七、其它問題

表中只有一條有名字的記錄，此時查詢名字!=a預期的結果應該是想查出來剩余的兩條記錄，會發(fā)現(xiàn)與預期結果不匹配。

到此這篇關于為什么數(shù)據(jù)庫字段建議設置為NOT NULL的文章就介紹到這了,更多相關數(shù)據(jù)庫字段NOT NULL內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論