在sql的優化中，會有同學提到一點：使用enum字段類型，代替其他tinyint等類型。以前這也是不少人喜歡優化的，但是現在細想，是非常不合理的。
優點：
1.可以設置區間范圍，比如設置性別：1男2女3未知。如果這是出現一個非1、2、3類型的，一眼就是臟數據了。
缺點：
1.數據遷移的時候，他幾乎不可能被其他數據庫所支持，如果enum里面是字符串，對於其他數據庫來說就更郁悶了，還不能設為tinyint等類型的字段（enum雖然可以存儲字符串，但對於內部來說，還是以順序進行索引，比如'a','b','c'，我們也可以用索引值來獲取值select * from tbl_name whre enum = 2，這與select * from tbl_name where enum = 'b'等義）如果你看明白了這兩句SQL為什么等義，那么你也就可以了解為什么不主張用enum字段了。
2.如果一個設計不合理的ENUM字段，比如一個enum字段的范圍是('0','1','2','3')，這時候，你會不會哭呢？要知道enum的枚舉值對應的索引是從1開始的。比如：執行INSERT INTO test1(id, sex) VALUES (1, 1)；表中實際存儲
你就會發現，你插入的並不是1，而是0。
3.更有甚者，由於enum的區間也是可以變動的，如果你在enum的枚舉字段范圍中加一個值，並且不是加在最后，那么也就相當於，你把原來的范圍都改變了索引值，試想這又是多么一個恐怖的事情？
總結：
如果你的系統中真的已經使用了mysql的enum字段類型，請在查詢的時候直接查詢值（並加上單引號），這樣就不會使用enum自身隱藏的索引值來獲取結果了。【順便說一下，enum的默認索引是從NULL開始，如果你允許NULL並default NULL】
建議：
如果字段是字符串，並且長度固定，可以嘗試用char，如果是數值型，還是用tinyint<只占一個字節>吧，比較安全穩定，而且即使遷移，問題也不大。
如有錯誤，歡迎熱心指正。