mysql schema設計中應避免的陷阱

謹記紅字：

1. 表中謹防太多列：

　　MySQL 的存儲引擎API 工做時須要在服務器層和存儲引擎層之間經過行緩衝格式拷貝數據，而後在服務器層將緩衝內容解碼成各個列。從行緩衝中將編碼過的列轉換成行數據結構的操做代價是很是高的。MyISAM 的定長行結構實際上與服務器層的行結構正好匹配，因此不須要轉換。然而，MyISAM 的變長行結構和InnoDB 的行結構則老是須要轉換。轉換的代價依賴於列的數量。當咱們研究一個CPU 佔用很是高的案例時，發現客戶使用了很是寬的表（數千個字段），然而只有一小部分列會實際用到，這時轉換的代價就很是高。若是計劃使用數千個字段，必須意識到服務器的性能運行特徵會有一些不一樣。

 

2. 太多關聯：

　　所謂的「實體- 屬性- 值」（EAV）設計模式是一個常見的糟糕設計模式，尤爲是在MySQL 下不能靠譜地工做。MySQL 限制了每一個關聯操做最多隻能有61 張表，可是EAV 數據庫須要許多自關聯。咱們見過很多EAV 數據庫最後超過了這個限制。事實上在許多關聯少於61 張表的狀況下，解析和優化查詢的代價也會成爲MySQL的問題。一個粗略的經驗法則，若是但願查詢執行得快速且併發性好，單個查詢最好在12 個表之內作關聯。

 

3. 全能的枚舉：