我正在進行優化，此刻。mysql空列
我傾向於使用多個表，所以我沒有空的列。
我的問題是，空列是一個大問題？我不是在談論空間。我指的是索引，數據檢索等的速度...
我的賭注的例子是當我有一個簡單的customers表，並且一些列並不總是被填充。像電子郵件，dob，ssn或pic。我想說大多數時間他們沒有填寫。
這使我創建一個新的表來容納輔助數據。 但如果我將這些列與其餘客戶信息放在同一個表中，它會真的起作用嗎？
如果我這樣做，那麼會有很多空列的記錄。這導致我想知道當記錄數量巨大時這會影響性能。
如果您使用的是優化踢，我的建議是下車吧:-)
優化是什麼，應該響應性能問題，不是心血來潮來完成。如果沒有性能問題，所有優化都是浪費精力。
由於大多數查詢都應該儘可能使用索引來決定要獲取哪些行，所以空字段很少會在正確設計的模式中對數據檢索產生很大影響。一旦行被發現，那就是當你去表中獲取實際數據。
索引速度不會因爲列存儲在另一個表中而改變。如果它需要被索引，那麼它需要被索引。
我更喜歡我的模式儘可能簡單（儘管大部分時間跟在3NF之後），以避免不必要的連接。
如果將它們存儲爲可變長度字段（例如：VARCHAR），則空列不會佔用太多（任何？）空間。與只有具有固定長度字段的表相比，這是以較慢的查找爲代價的。
我個人認爲可以有空列，即使有很多列（也稱爲稀疏表）。一些數據庫甚至對稀疏表進行了優化。如果你開始擁有許多額外的表格，你的邏輯將變得更加複雜，並且使維護參照完整性變得更加困難。
你可以在你的customers表中做什麼，是有一個額外的customer_profiles表與customers表有1：1的關係。在表中存儲必要的信息customers和其餘的（即：你不需要，每次你查找客戶）。
使用外部表來託管輔助數據是其中一個選項，就像可空列一樣。
它可以節省一些空間，但需要更多資源來加入表格。
如果您的模型是稀疏矩陣（大量屬性，其中大多數屬性不會被定義），比存儲和掃描這些屬性的成本甚至可能超過JOIN的成本。
但是，如果使用附加表格，則無法創建包含來自不同表格的兩個屬性的索引。
關係模型通常允許使用多種方法來實現ER模型，這正是說明它的原因。
您可能需要閱讀這篇文章：