高效能MySQL（三） Schema與資料型別優化

mysql schema設計中的問題

mysql支援的資料型別非常多，選擇正確的資料型別對於獲得高效能至關重要。

下面幾個簡單的原則有助於做出更好的選擇：

更小的通常更好簡單就好避免null

本篇預設儲存引擎是innodb

有兩種型別的數字：整數和實數。

如果儲存整數，可以使用這幾種整數型別：tinyint、smallint、mediumint、int、bigint。分別使用8，16,24,32,64位儲存空間。它們可以儲存的範圍從-2^(n-1)到2^(n-1)-1。

整數型別有可選的unsigned屬性，表示不允許負值，這大致可以使整數的上限提高一倍。有符號和無符號型別使用相同的儲存空間，並具有相同的效能，因此可以根據實際情況選擇合適的型別。

實數的話，decimal。

varchar和char是主要的字串型別。

varchar：

通常用於儲存可變長字串，是最常見的字串資料型別。它比定長型別更節省空間，因為它僅使用必要的空間。

varchar會使用乙個或兩個位元組來儲存空間的大小，但是，由於行是變長的，在update的時候就比較麻煩了。如果乙個行占用的空間增長，但是這一頁沒有更多的空間可以使用了，innodb會需要**頁來使行可以放進頁內。

這種情況下適合使用varchar：

字串列的最大長度比平均長度大很多；

列的更新很少，所以碎片不是問題；

使用了像utf-8 這樣複雜的字符集，每個字元都使用不同的位元組數進行儲存。

char：

char型別是定長的，當儲存char值時，mysql會刪除所有的末位空格。char值會根據需要採用空格進行填充以方便比較。

char適合儲存很短的字串，或者所有的值都接近乙個長度。對於經常變更的值，char 也比varchar要好，因為定長的char型別不容易產生碎片。對於非常短的列，char也比varchar更有效率，例如就存乙個字元的時候，varchar還要有乙個位元組來記錄長度。

再次重申：資料如何儲存取決於儲存引擎，而本篇我們只講innodb

blog和text都是為儲存很大的資料而設計的字串資料型別，分別採用二進位制和字串方式儲存。

它們分別屬於兩組不同的資料型別家族：

tinytext、smalltext、text、mediumtext、longtext

tinyblog、smallblog、blog、mediumblog、longblog

有時候可以使用列舉列代替常用的字串型別。

列舉列可以把一些不重複的字串儲存成乙個預定義的集合。mysql在儲存列舉時非常緊湊，會根據列表值的數量壓縮到乙個或者兩個位元組中，mysql會在內部將每個值在列表中的位置儲存成整數，並且在表的.frm檔案中儲存「數字 - 字串」對映關係的查詢表。

下面有乙個栗子：

盡量避免使用數字作為enum列舉常量。

雖然有一些好的或換的的設計原則，但也有一些問題是由mysql的實現機制導致的，這意味著有可能犯一些只在mysql下發生的特定錯誤。

1、太多的列

從行緩衝中將編碼過的列轉換成資料結構的操作代價是非常高的。

如果計畫使用數千個字段，必須意識到伺服器的效能執行特徵會有一些不同。

2、太多的關聯

如果希望查詢執行的快速且併發性好，單個查詢最好在12個表以內做關聯。

3、全能的列舉

應避免過過度使用列舉。