**更小的通常更好** 一般情況下,應該盡量使用可以正確存儲數據的最小數據類型.更小的數據類型通常更快,因為他們占用更少的磁盤,內存和cpu緩存,并且處理時需要的cpu周期更少 但是要確保沒有低估需要存儲的值的范圍,因為在schema中的多個地方增加數據類型的范圍是一個非常耗時和痛苦的操作. 如果無法確定那個數據類型是最好的.要選擇你認為不會超過范圍的最小類型(如果系統不是很忙或者存儲的數據量不多或者是在可以輕易修改設計的早期階段) **簡單就好** 簡單的數據類型的操作通常需要更少的cpu周期.例如,整形比字符操作代價更低. 因為字符集和校對規則(排序規則)使字符比較比整形比較更為復雜 這里有兩個例子:一個是應該使用mysql內建的類型(date time datatime),而不是字符串來存儲日期和時間,另外一個是應該用整形存儲IP地址 **盡量避免使用null** 很多表都包含可為null的列,即使應用程序并不需要保持NULL也是如此,這是因為可為NULL是列的默認屬性. 通常情況下最好指定列為not null,除非真的需要存儲NULL值 如果查詢中包含可為null的列,對mysql來說更難優化,因為可為null的列使得索引,索引統計和值比較都更復雜.可為null的列會使用更多的存儲空間,在mysql中也要特殊處理 當可為null的列被索引的時候,每一個索引記錄需要一個額外的字節,在myisam里甚至還可能導致固定大小的索引(例如只有一個整數列的索引)變成可變大小的索引 通常把可為null的列改為not null帶來的性能提升的比較小,所以(調優時)沒有必要首先在現有的schema中查找并修改掉這種情況,除非確定這會導致問題. 但是,如果計劃在列上建索引,就應該盡量避免設計成可為null的列 Innodb使用單獨的位(bit)存儲NULL值,所以對于稀疏數據(很多值為null,只有少數行有非null值)有很好的空間效率.但是這不適用于myisam 例如datetime和timesamp列都可以存儲相同類型的數據:時間和日期,精確到秒,然而timestamp只使用datetime一半的存儲空間,并且會根據時區變化,具有特殊的自動更新能力 另一方面,timestamp允許的時間范圍要小的多,有時候它的特殊能力會成為障礙 **慷慨是不明智** 使用`varchar(5)` 和 `varchar(200)` 存儲 'hello' 的空間開銷是一樣的.那么使用更短的列有什么優勢嗎? 事實證明有很大的優勢.更長的列會消耗更多的內存,因為mysql通常會分配固定大小的內存塊來保存內部的值 尤其是使用內存臨時表進行排序或操作時會特別糟糕.在利用磁盤臨時表進行排序時也同樣糟糕 所以最好的策略是分配真正需要的空間 **使用枚舉(ENUM)代替字符串類型** 有時候可以使用枚舉列代替常用的字符串類型. 枚舉列可以把一些不重復的字符串存儲成一個預定義的集合. mysql在存儲枚舉時非常緊湊,會根據列表值的數量壓縮到一個或者兩個字節中 mysql在內部會將每個值在列表中的位置保存為整數,并且在表的.frm文件中保存"數字-字符串"映射關系的'查找表'  一種繞過這種限制的方式是按照需要的順序來定義枚舉列, 另外也可以在查詢中使 `field()` 函數顯式的指定排序順序,但這會導致mysql無法利用索引消除排序  我們用varchar和enum列的速度