雖然熟練掌握SQL的人對於Null不會有什麼疑問,但總結得很全的文章仍是很難找,看到一篇英文版的, 感受還不錯。 sql
Tony Hoare 在1965年發明了 null 引用, 並認爲這是他犯下的「幾十億美圓的錯誤」. 即使是50年後的今天, SQL中的 null 值仍是致使許多常見錯誤的罪魁禍首. 數據庫
咱們一塊兒來看那些最使人震驚的狀況。 函數
下面的2個查詢,無論表 users 中有多少條記錄,返回的記錄都是0行: spa
select * from users where deleted_at = null; – result: 0 rows select * from users where deleted_at != null; – result: 0 rows
怎麼會這樣子? 一切只由於 null 是表示一種「未知」的類型。也就是說,用常規的比較操做符(normal conditional operators)來將 null 與其餘值比較是沒有意義的。 Null 也不等於 Null(近似理解: 未知的值不能等於未知的值,二者間的關係也是未知,不然數學和邏輯上就亂套了)。 code
– 注意: 下面的SQL適合於MySQL,若是是Oracle,你須要加上 … from dual; orm
select null > 0; – result: null select null < 0; – result: null select null = 0; – result: null select null = null; – result: null select null != null; – result: null
將某個值與 null 進行比較的正確方法是使用 is 關鍵字, 以及 is not 操做符: 排序
select * from users where deleted_at is null; – result: 全部被標記爲刪除的 users
若是想要判斷兩列的值是否不相同,則可使用 is distinct from: 編譯器
select * from users where has_address is distinct from has_photo – result: 地址(address)或照片(photo)二者只有其一的用戶
子查詢(subselect)是一種很方便的過濾數據的方法。例如,若是想要查詢沒有任何包的用戶,能夠編寫下面這樣一個查詢: 數學
select * from users where id not in (select user_id from packages)
但此時倘若 packages 表中某一行的 user_id 是 null 的話,問題就來了: 返回結果是空的! 要理解爲何會發生這種古怪的事情, 咱們須要理解SQL編譯器究竟幹了些什麼. 下面是一個更簡單的示例: it
select * from users where id not in (1, 2, null)
這個SQL語句會被轉換爲:
select * from users where id != 1 and id != 2 and id != null
咱們知道,id != null 結果是個未知值, null. 而任意值和 null 進行 and 運算的結果都是 null, 因此至關於沒有其餘條件. 那麼出這種結果的緣由就是 null 的邏輯值不爲 true.
若是條件調換過來, 查詢結果就沒有問題。 如今咱們查詢有package的用戶.
select * from users where id in (select user_id from packages)
一樣咱們可使用簡單的例子:
select * from users where id in (1, 2, null)
這條SQL被轉換爲:
select * from users where id = 1 or id = 2 or id = null
由於 where 子句中是一串的 or 條件,因此其中某個的結果爲 null 也是可有可無的。非真(non-true)值並不影響子句中其餘部分的計算結果,至關於被忽略了。
在排序時, null 值被認爲是最大的. 在降序排序時(descending)這會讓你很是頭大,由於 null值排在了最前面。
下面這個查詢是爲了根據得分顯示用戶排名, 但它將沒有得分的用戶排到了最前面!
select name, points from users order by 2 desc; – points 爲 null 的記錄排在全部記錄以前!
解決這類問題有兩種思路。最簡單的一種是用 coalesce 消除 null的影響:
– 在輸出時將 null 轉換爲 0 : select name, coalesce(points, 0) from users order by 2 desc; – 輸出時保留 null, 但排序時轉換爲 0 : select name, points from users order by coalesce(points, 0) desc;
還有一種方式須要數據庫的支持,指定排序時將 null 值放在最前面仍是最後面:
select name, coalesce(points, 0) from users order by 2 desc nulls last;
固然, null 也能夠用來防止錯誤的發生,好比處理除數爲0的數學運算錯誤。
除數爲0是一個很是 egg-painfull 的錯誤。昨天還運行得好好的SQL,忽然被0除一會兒就出錯了。一個經常使用的解決方法是先用 case 語句判斷分母(denominator)是否爲0,再進行除法運算。
select case when num_users = 0 then 0 else total_sales/num_users end;
ase 語句的方式其實很難看,並且分母被重複使用了。若是是簡單的狀況還好,若是分母是個很複雜的表達式,那麼悲劇就來了: 很難讀,很難維護和修改,一不當心就是一堆BUG.
這時候咱們能夠看看 null 的好處. 使用 nullif 使得分母爲0時變成 null. 這樣就再也不報錯, num_users = 0 時返回結果變爲 null.
select total_sales/nullif(num_users, 0); nullif 是將其餘值轉爲 null, 而Oracle的 nvl 是將 null 轉換爲其餘值。
若是不想要 null,而是但願轉換爲 0 或者其餘數, 則能夠在前一個SQL的基礎上使用 coalesce函數:
select coalesce(total_sales/nullif(num_users, 0), 0); null 再轉換回0
Tony Hoare 也許會後悔本身的錯誤, 但至少 null 存在的問題很容易地就解決了. 那麼快去練練新的大招吧,今後遠離 null 挖出來的無效大坑(nullifying)!