mysql schema設計中應避免的陷阱

標籤：sch   通過   nbsp   超過   緩衝   枚舉   儲存   資料   問題   

謹記紅字：

1. 表中謹防太多列：

　　MySQL 的儲存引擎API 工作時需要在伺服器層和儲存引擎層之間通過行緩衝格式拷貝資料，然後在伺服器層將緩衝內容解碼成各個列。從行緩衝中將編碼過的列轉換成行資料結構的操作代價是非常高的。MyISAM 的定長行結構實際上與伺服器層的行結構正好匹配，所以不需要轉換。然而，MyISAM 的變長行結構和InnoDB 的行結構則總是需要轉換。轉換的代價依賴於列的數量。當我們研究一個CPU 佔用非常高的案例時，發現客戶使用了非常寬的表（數千個欄位），然而只有一小部分列會實際用到，這時轉換的代價就非常高。如果計劃使用數千個欄位，必須意識到伺服器的效能運行特徵會有一些不同。

 

2. 太多關聯：

　　所謂的“實體- 屬性- 值”（EAV）設計模式是一個常見的糟糕設計模式，尤其是在MySQL 下不能靠譜地工作。MySQL 限制了每個關聯操作最多隻能有61 張表，但是EAV 資料庫需要許多自關聯。我們見過不少EAV 資料庫最後超過了這個限制。事實上在許多關聯少於61 張表的情況下，解析和最佳化查詢的代價也會成為MySQL的問題。一個粗略的經驗法則，如果希望查詢執行得快速且並發性好，單個查詢最好在12 個表以內做關聯。

 

3. 全能的枚舉：

　　

mysql schema設計中應避免的陷阱