這一部分提供了如何選擇資料型別來幫助提高查詢執行速度的一些指導：
說，這一點尤其突出，因為在那些情況下，效能更容易受到磁碟碎片的影響。
在使用可變長度的資料行的時候，由於記錄長度不同，在多次執行刪除和更新操作之後，資料表的碎片要多一些。你必須使用optimize table來定期維護其效能。固定長度的資料行沒有這個問題。
如果出現資料表崩潰的情況，那麼資料行長度固定的表更容易重新構造。使用固定長度資料行的時候，每個記錄的開始位置都可以被檢測到，因為這些位置都是固定記錄長度的倍數，但是使用可變長度資料行的時候就不一定了。這不是與查詢處理的效能相關的問題，但是它一定能夠加快資料表的修復速度。
儘管把myisam資料表轉換成使用固定長度的資料列可以提高效能，但是你首先需要考慮下面一些問題：
固定長度的資料列速度較快，但是占用的空間也較大。char(n)列的每個值（即使是空值）通常佔n個字元，這是因為把它儲存到資料表中的時候，會在值的後面新增空格。varchar(n)列占有的空間較小，因為只需要分配必要的字元個數用於儲存值，加上一兩個位元組來儲存值的長度。因此，在char和varchar列之間進行選擇的時候，實際上是時間與空間的對比。如果速度是主要的考慮因素，那麼就使用char資料列獲取固定長度列的效能優勢。如果空間很重要，那麼就使用varchar資料列。總而言之，你可以認為固定長度的資料行可以提高效能，雖然它占用了更大的空間。但是對於某些特殊的應用程式，
你可能希望使用兩種方式來實現某個資料表，然後執行測試來決定哪種情況符合應用程式的需求。
即使願意使用固定長度型別，有時候你也沒有辦法使用。例如，長於255個字元的字串就無法使用固定長度型別。
memory資料表目前都使用固定長度的資料行儲存，因此無論使用char或varchar列都沒有關係。兩者都是作為char型別處理的。
對於innodb資料表，內部的行儲存格式沒有區分固定長度和可變長度列（所有資料行都使用指向資料列值的頭指標），因此在本質上，使用固定長度的char列不一定比使用可變長度varchar列簡單。因而，主要的效能因素是資料行使用的儲存總量。由於char平均占用的空間多於varchar，因
此使用varchar來最小化需要處理的資料行的儲存總量和磁碟i/o是比較好的。
對於bdb資料表，無論使用固定長度或可變長度的資料列，差別都不大。兩種方法你都可用試一下，執行一些實驗測試來檢測是否存在明顯的差別。
把資料列定義成不能為空（not null）。這會使處理速度更快，需要的儲存更少。它有時候還簡化了查詢，因為在某些情況下你不需要檢查值的null屬性。
考慮使用enum資料列。如果你擁有的某個資料列的基數很低（包含的不同的值數量有限），那麼可以考慮把它轉換為enum列。enum值可以被更快地處理，因為它們在內部表現為數值。
使用procedure analyse()。執行procedure analyse()可以看到資料表中列的情況：
select*from tbl_name procedure
analyse();
select
*from tbl_name procedure analyse(16,256);
輸出的每一列資訊都會對資料表中的列的資料型別提出優化建議。第二個例子告訴procedure analyse()不要為那些包含的值多於16個或者256位元組的enum型別提出建議。如果沒有這樣的限制，輸出資訊可能很長；enum定義通常很難閱讀。
**：
MYSQL查詢優化 資料型別與效率
這一部分提供了如何選擇資料型別來幫助提高查詢執行速度的一些指導 如果出現資料表崩潰的情況，那麼資料行長度固定的表更容易重新構造。使用固定長度資料行的時候，每個記錄的開始位置都可以被檢測到，因為這些位置都是固定記錄長度的倍數，但是使用可變長度資料行的時候就不一定了。這不是與查詢處理的效能相關的問題，但...
MySQL查詢優化系列之資料型別與效率
這一部分提供了如何選擇資料型別來幫助提高查詢執行速度的一些指導 如果你可以選擇資料行的儲存格式，那麼應該使用最適合儲存引擎的那種。對於myisam資料表，最好使用固定長度的資料列代替可變長度的資料列。例如，讓所有的字元列用char型別代替varchar型別。權衡得失，我們會發現資料表使用了更多的磁碟...
MySQL資料型別 選擇與優化
mysql資料型別 數值 日期 時間 字串 字元 型別 復合型別。一般情況下選擇可以正確儲存資料的最小資料型別。越小的資料型別通常更快，占用磁碟，記憶體和cpu快取更小，大大減少io開銷。簡單的資料型別的操作通常需要更少的cpu週期。例如 整型比字元操作代價要小得多，因為字符集和校對規則 排序規則 ...