在sql的優化中，會有同學提到一點：使用enum欄位類型，代替其他tinyint等類型。以前這也是不少人喜歡優化的，但是現在細想，是非常不合理的。 優點： 1.可以設置區間範圍，比如設置性別：1男2女3未知。如果這是出現一個非1、2、3類型的，一眼就是臟數據了。 缺點： 1.數據遷移的時候，他幾乎不 ...
在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<只占一個位元組>吧，比較安全穩定，而且即使遷移，問題也不大。
如有錯誤，歡迎熱心指正。
