高效的模型設計

適度冗餘- 讓Query儘量減少Join

大欄位垂直分拆- summary 表優化

大表水平分拆- 基於型別的分拆優化

統計表- 準實時優化

合適的資料型別

優化資料型別提高效能的主要原理在於以下幾個方面：

①通過選用更“小”的資料型別減少儲存空間，使查詢相同資料需要的IO資源降低。

②通過合適的資料型別加速資料的比較。

數字日期型別

存放長度基本固定的一些資料型別的儲存長度和取值範圍：

字元儲存型別

CHAR[(M)]型別屬於靜態長度型別，存放長度完全以字元數來計算，所以最終的儲存長度是基於字符集的，如latin1 則最大儲存長度為255 位元組，但是如果使用gbk 則最大儲存長度為510 位元組。CHAR 型別的儲存特點是不管我們實際存放多長資料，在資料庫中都會存放M 個字元，不夠的通過空格補上，M 預設為1。雖然CHAR 會通過空格補齊存放的空間，但是在訪問資料的時候，MySQL 會忽略最後的所有空格，所以如果我們的實際資料中如果在最後確實需要空格，則不能使用CHAR 型別來存放。在MySQL5.0.3 之前的版本中，如果我們定義CHAR 的時候M 值超過255，MySQL 會自動將CHAR 型別進行轉換為可以存入對應資料量的TEXT 型別， 如CHAR(1000)會自動轉換為TEXT ， CHAR(10000)則會轉為MEDIUMTEXT。而從MySQL5.0.3 開始，所有超過255 的定義MySQL 都會直接拒絕並給出錯誤資訊，不再自動轉換。

VARCHAR[(M)]屬於動態儲存長度型別，僅存佔用實際儲存資料的長度。其存放的最大長度與MySQL版本有關，在5.0.3 之前的版本VARCHAR 以字元數控制最儲存的最大長度，最大隻能存放255 個字元，佔用儲存空間的實際大小與字符集有關。但是從5.0.3 開始，VARCHAR 的最大儲存限制已經更改為位元組數限制了，擴充套件到可以存放65535 bytes 的資料，不同的字符集可能存放的字元數並不一樣。也就是說，在MySQL5.0.3 之前的版本，M 所代表的是字元數，而從5.0.3 版本開始，M 的代表意思已經是位元組數了。VARCHAR 的儲存特點是不管我們設定M 為多大的值，真正佔用的儲存空間都只有我們所存入的實際資料的大小，和CHAR 不同的是VARCHAR 會保留我們存入資料最後的空格，也就是說我們存入是什麼樣，MySQL返回給我們的也會是什麼樣。在VARCHAR 型別欄位的資料中，MySQL 會在每個VARCHAR 資料中使用1 個或者2 個位元組用來存放VARCHAR 資料的實際長度，當我們的實際資料在255 位元組之內的時候，會使用1 位元組來存放實際長度，而大於255 位元組的時候，則需要使用2 位元組來存放。

TINYTEXT，TEXT，MEDIUMTEXT 和LONGTEXT 這四種類型同屬於一種儲存方式，都是動態儲存長度型別，不同的僅僅是最大長度的限制。四種類型的定義都是通過最大字元數來限制，但是他們的字元數限制實際上是可以理解為位元組數限制的，因為當我們使用多位元組字符集的時候，實際能存放的字元數並沒最大字元數那麼多，而是以單位元組字元來計算的字元數。此外，由於是動態儲存長度型別，所以和VARCHAR 一樣，每個欄位資料之前都需要一個存放實際長度的空間。TINYTEXT 需要1 個位元組來存放，TEXT需要2 個位元組，MEDIUMTEXT 和LONGTEXT 則分別需要3 個和4 個位元組來存放實際資料長度。實際上，出了MySQL 內嵌的最大長度限制之外， 他們還受到客戶端與伺服器端的網路通訊緩衝區最大值（max_allowed_packet）的限制。

其他常用型別