文章目錄
- 選擇優化的資料型別
- 整數型別
- 字串型別
- BLOG 和 TEXT 型別
- 使用列舉（ENUM）代替字串
- 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 型別
BLOG和TEXT都是為存盤很大的資料而設計的字串資料型別，分別采用二進制和字串方式存盤，
它們分別屬于兩組不同的資料型別家族：
TINYTEXT、SMALLTEXT、TEXT、MEDIUMTEXT、LONGTEXT
TINYBLOG、SMALLBLOG、BLOG、MEDIUMBLOG、LONGBLOG
使用列舉（ENUM）代替字串
有時候可以使用列舉列代替常用的字串型別，
列舉列可以把一些不重復的字串存盤成一個預定義的集合，MySQL在存盤列舉時非常緊湊，會根據串列值的數量壓縮到一個或者兩個位元組中，MySQL會在內部將每個值在串列中的位置保存成整數，并且在表的.frm檔案中保存 “數字 - 字串”映射關系的查找表，
下面有一個栗子：
盡量避免使用數字作為ENUM列舉常量，
MySQL schema設計中的問題
雖然有一些好的或換的的設計原則，但也有一些問題是由MySQL的實作機制導致的，這意味著有可能犯一些只在MySQL下發生的特定錯誤，
1、太多的列
從行緩沖中將編碼過的列轉換成資料結構的操作代價是非常高的，
如果計劃使用數千個欄位，必須意識到服務器的性能運行特征會有一些不同，
2、太多的關聯
如果希望查詢執行的快速且并發性好，單個查詢最好在12個表以內做關聯，
3、全能的列舉
應避免過過度使用列舉，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/262963.html
標籤：其他
上一篇：Web全堆疊~38.Vue