mysql支援的資料型別很多，選擇正確的資料型別對於獲得高效能至關重要，不管儲存哪種資料型別，下面幾個簡單原則都有助於我們做出更好的選擇。
1：更小的通常更好，更小的資料型別通常更快，因為它們占用更少的磁碟，記憶體和cpu快取，並且處理時需要的cpu週期也更少。（但是要確保不會低估要儲存值的範圍）。
2：簡單就好，簡單的資料型別操作通常需要更少的cpu週期，例如整型比字串的操作代價更低，因為字符集和排序規則比較整型更為複雜。
3：盡量避免null,如果查詢中包含可為null 的列，對mysql來說更難優化，因為可為空的列使得索引，索引統計和值都比較複雜。可為null 的列會使用更多的儲存空間，在mysql裡也需要做特殊處理。當可為null的列被索引時，每個索引記錄需要乙個額外的位元組，在myisam裡甚至還有可能導致固定大小的索引變成可變大小的索引。當然也有特殊情況，innodb使用單獨的bit儲存null值，有很好的空間效率，但不適用於myisam。
整數型別：tinyint ,smallint,mediumint,int,bigint
tinyint
從 0 到 255 的整型資料。儲存大小為 1 位元組
smallint
從 -2^15 (-32,768) 到 2^15 - 1 (32,767) 的整型資料。儲存大小為 2 個位元組
mediumint
從 -2^23 (-8388608) 到 2^23 - 1 (8388608) 的整型資料。儲存大小為 3個位元組
int
從 -2^31 (-2,147,483,648) 到 2^31 - 1 (2,147,483,647) 的整型資料（所有數字）。儲存大小為 4 個位元組。int 的 sql-92 同義字為 integer。
bigint
從 -2^63 (-9223372036854775808) 到 2^63-1 (9223372036854775807) 的整型資料（所有數字）。儲存大小為 8 個位元組。
整數型別後面跟的是顯示的寬度。m指示最大顯示寬度。最大有效顯示寬度是255。顯示寬度與儲存大小或型別包含的值的範圍無關。
字串型別 :varchar char
varchar用於儲存可變長度字串，它比定長型別更節省空間。varchar需要使用1或者2兩個額外位元組記錄字串長度，如果列的最大長度小於等於255，則需要1個位元組表示，如果大於255則需要2個位元組表示。如varchar（10）則需要11個位元組儲存空間，varchar（300）則需要302個位元組儲存空間； varchar節省了儲存空間，對效能也有幫助。但是由於行時邊長的，在update時候可能使當前行長度變得比以前長，這就導致需做更多的額外工作。
如果乙個行占用的空間增長在頁內沒有更多空間可以儲存，myisam會將頁拆成不同的片段儲存，innodb則需要**頁來使行能放入頁內。
字串列的最大長度比平均長度大很多，並且很少更新那麼很適合用varchar作儲存。
在mysql5.0或者更高版本， 儲存時會保留末尾空格，4.1或更老版本時會刪除末尾空格。
innodb會把過長的varchar儲存為blob。
char型別是定長的，對於經常變更的值，char比varchar更好，因為定長的char型別不容易產生碎片。對於非常短的列 char在儲存空間上也更有效率。
使用varchar（3）對比 varchar（300）來儲存 『php』的優勢？
更長的列會分配更多的記憶體，mysql通常會分配固定大小的記憶體塊來儲存內部值。尤其在記憶體臨時表進行排序時會表現特別糟糕。
MySQL資料型別優化
mysql資料型別眾多，選擇正確的資料型別對於獲得高效能至關重要。遵從以下幾條原則有助力做出更好的選擇。1 更小的資料型別。更小的資料型別通常更快，因為它們占用更少的磁碟 記憶體和cpu快取，並且處理時需要的cpu週期也更少。但也要確保自己沒有低估需要的儲存範圍。2 簡單的資料型別。簡單的資料型別通...
mysql 資料型別優化
1 更小的通常更好 更小的資料型別，更快速，因為占用更小的磁碟，cpu,快取 只要保證你的資料最大值不超過你的資料型別範圍即可 2 簡單就好 簡單的資料型別操作需要更少的cpu週期，整型比字元操作代價更低 例如時間型別用date,datetime等，不用字串 還有ip位址用整型等 3 盡量避免nul...
mysql優化（一） 資料型別優化
mysql支援的資料型別非常多，選擇正確的型別對獲取高效能至關重要。更小的通常更好 一般情況下使用正確儲存資料的最小資料型別，因為它們占取更小的磁碟，記憶體和cpu快取 簡單就好 例如整型比字元操作代價更低，如採用mysql內建型別 date，time，datatime 儲存時間和日期而不是字串，另...