慎用mysql的enum字段

這兩天有趣的事情很是多，好比，所謂的QQ一些內部培訓資料流出，網上各大網盤啥的流量一會兒就很是高了。我固然也不當心就下載了一份，尚未看，不過好象什麼百度的資料上已經有在線看了。由於本身也沒有看，因此也不太清楚這玩意是真是假。

OK，上正文，16日的MYSQL專場，對於mysql優化講的較詳細的應該算是楊濤濤，他對MYSQL的一些字段類型進行了些介紹，包括他們所含 的字節長度，來介紹給咱們讓咱們瞭解如何對數據庫進行優化，好比，儘可能不要用bigint，由於，這在項目中幾乎不可能會被用上而他們佔的字節長度倒是在int中最長的，在數據量大的時候，既佔空間，又影響速度。

還介紹了datetime和timstamp等的區別（更多能夠看我之前寫的連載，裏面也有介紹）

不過，他惟獨沒有提起ENUM字段，提及這個ENUM，它卻是mysql的一個特點字段，在之前不少人喜歡用它，由於他能夠設置字段的區間範圍，會讓值能夠被數據庫所控制，不至於出現意料不到的值（好比，字段只想有0和1，結果出現了2，那2就是贓數據了）

但ENUM帶來的問題也很多，好比數據遷移的時候，他幾乎不可能被其餘數據庫所支持，若是enum裏面是字符串，對於其餘數據庫來講就更鬱悶了，還不能設爲tinyint等類型的字段（enum雖然能夠存儲字符串，但對於內部來講，仍是以順序進行索引，好比'a','b','c'，咱們也能夠用索引值來獲取值select * from tbl_name whre enum = 2，這與select * from tbl_name where enum = 'b'等義）若是你看明白了這兩句SQL爲何等義，那麼你也就能夠了解爲何不主張用enum字段了。

由於，若是一個設計不合理的ENUM字段，給程序員帶來的就徹底是夢魘了，好比一個enum字段的範圍是('0','1','2','3','4','5')，我想這時候，你會不會哭呢？要知道enum的枚舉值對應的索引是從1開始的，所以，insert into table (enum)values(1)，你知道是插的什麼值嗎？你select from table一下，你就會發現，你插入的並非1，而是0。

更有甚者，因爲enum的區間也是能夠變更的，若是你在enum的枚舉字段範圍中加一個值，而且不是加在最後，那麼也就至關於，你把原來的範圍都改變了索引值，試想這又是多麼一個恐怖的事情？

所以，若是你的系統中真的已經使用了mysql的enum字段類型，請在查詢的時候直接查詢值（並加上單引號），這樣就不會使用enum自身隱藏的索引值來獲取結果了。【順便說一下，enum的默認索引是從NULL開始，若是你容許NULL並default NULL】

之因此提起這個，是在用shopnc系統的時候發現大量這樣的字段，讓人很是鬱悶，幾乎沒有辦法優化（若是是純數值型，仍是建議採用tinyint字段吧，畢竟它也只佔一個字節，即便出現贓數據，也能夠被接受，不象enum，若是純數字型範圍，更改了索引，你就不知道你查詢的值是否正確了）

所以建議，若是字段是字符串，而且長度固定，能夠嘗試用char，若是是數值型，仍是用tinyint吧，比較安全穩定，並且即便遷移，問題也不大。