MySQL schema 設計中的陷阱
雖然有一些普遍的好或壞的設計原則但也有一些問題是由MySQL 的實現機制導致的這意味著有可能犯一些只在MySQL 下發生的特定錯誤本節我們討論設計MySQL 的schema 的問題這也許會幫助你避免這些錯誤並且選擇在MySQL 特定實現下工作得更好的替代方案
太多的列
MySQL 的存儲引擎API 工作時需要在服務器層和存儲引擎層之間通過行緩沖格式拷貝數據然後在服務器層將緩沖內容解碼成各個列從行緩沖中將編碼過的列轉換成行數據結構的操作代價是非常高的MyISAM 的定長行結構實際上與服務器層的行結構正好匹配所以不需要轉換然而MyISAM 的變長行結構和InnoDB 的行結構則總是需要轉換轉換的代價依賴於列的數量當我們研究一個CPU 占用非常高的案例時發現客戶使用了非常寬的表（數千個字段）然而只有一小部分列會實際用到這時轉換的代價就非常高如果計劃使用數千個字段必須意識到服務器的性能運行特征會有一些不同
太多的關聯
所謂的實體 屬性 值（EAV）設計模式是一個常見的糟糕設計模式尤其是在MySQL 下不能靠譜地工作MySQL 限制了每個關聯操作最多只能有 張表但是EAV 數據庫需要許多自關聯我們見過不少EAV 數據庫最後超過了這個限制事實上在許多關聯少於 張表的情況下解析和優化查詢的代價也會成為MySQL的問題一個粗略的經驗法則如果希望查詢執行得快速且並發性好單個查詢最好在 個表以內做關聯
全能的枚舉
注意防止過度使用枚舉（ENUM）下面是我們見過的一個例子
如果這裡真和假兩種情況不會同時出現那麼毫無疑問應該使用枚舉列代替集合列
非此發明（Not Invent Here）的NULL
我們之前寫了避免使用NULL 的好處並且建議盡可能地考慮替代方案即使需要存儲一個事實上的空值到表中時也不一定非得使用NULL也許可以使用某個特殊值或者空字符串作為代替
但是遵循這個原則也不要走極端當確實需要表示未知值時也不要害怕使用NULL在一些場景中使用NULL 可能會比某個神奇常數更好從特定類型的值域中選擇一個不可能的值例如用 代表一個未知的整數可能導致代碼復雜很多並容易引入bug還可能會讓事情變得一團糟處理NULL 確實不容易但有時候會比它的替代方案更好
返回目錄高性能MySQL
編輯推薦
ASPNET MVC 框架揭秘
Oracle索引技術
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
From:http://tw.wingwit.com/Article/program/MySQL/201311/29680.html
