一般數據庫優化 - 正確的數據類型 - 為什麼要避免 NULL？

甲骨文建議：

Choose the correct data types and size to:
– Avoid NULLs
– Improve performance
– Protect data
– Use data compression where appropriate

我不明白為什麼我需要避免 NULL。請解釋。

雖然我確實使用 NULL 列，但存在成本。如果您進一步閱讀，您檢索到這個簡短列表的 Oracle 文件應該會解釋。

在某些情況下，NULL 表示數據類型存在問題和/或僅具有列。

• 考慮 PHONE_NUMBER NUMBER(15)：這可能有一個格式化的電話號碼列，並且對於像 1-800-CALL-NUM 這樣的數字可能為空。
• 其他列可能為 NULL，因為您無法收集填充它們所需的數據。如果您不太可能收集數據，請考慮刪除這些列。
• NULL 列可能屬於一個子類型。有一個包含類型相關數據的相關表可能是合適的。這將具有可選的 1 對 1（1 對 (0,1)）關係。
• NULL 列對於索引來說是有問題的。
• NULL 列可能與狀態相關，例如訂單上的 DATE_SHIPPED。在訂單發貨之前將其設為 NULL 是合適的。但是，將 has_shipped 指示符列設為 NULL 是不合適的。

始終可以將數據庫中的 NULL 列標準化。這樣做可能並不總是合適的。

我確實嘗試將 NULL 列放在最後。我之前已經在列順序上發布過。

避免NULLs在我的優化列表中非常低。我更喜歡說“NOT NULL在適當的地方使用”。這意味著如果您需要NULL，請繼續使用它。我確實在自己的表格中發現很少有NULL.

請參閱Rick 的 RoTs以獲得更長的建議列表；他們針對 MySQL，並來自 MySQL/MariaDB 多年的優化經驗。

該 Oracle 列表遺漏了兩個重要問題：

• 設置innodb_buffer_pool_size為可用RAM 的 70% 左右。 詳情。
• 如何“創建最佳索引”。

NULL有許多可能的“含義”，例如：

• 還不知道*_*
• 可選的
• 已移除

使用它可能NULL比使用另一列更有效。另一方面，為類似空的資訊選擇一個特殊值可能會更好，例如 0 或 -1 或：

ENUM('decline-to-state', 'male', 'female') NOT NULL

代替

ENUM('male', 'female') NULL

至於規範化，我說“規範化，但不要‘過度規範化’”。特別是，不要規範化任何“連續”值，例如FLOAT或DATE。

引用自：https://dba.stackexchange.com/questions/144124