慎使用sql的enum字段类型

　　在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<只占一个字节>吧，比较安全稳定，而且即使迁移，问题也不大。

 

如有错误，欢迎热心指正。