mysql数据类型之用 TINYINT(1) 还是 ENUM( true , false)？

在以往的经验中，如果遇到需要抉择是否用mysql的enum数据类型时，我基本不用思考的就会放弃ENUM()并用tinyint取而代之，原因就是我以前接触的哪些场景，均适合用

  在以往的经验中，如果遇到需要抉择是否用mysql的enum数据类型时，我基本不用思考的就会放弃 ENUM()并用tinyint取而代之，原因就是我以前接触的哪些场景，均适合用tinyint，也即在第一次选择了tinyint后就再也没认真研究关注过这两个字段类型了，而今天在开发 超凡商标管家 的途中遇到一个商标状态扩展的需求，需要建立一张大量存储0和1的字段的表，因为是大量0和1，所以我犹豫了下，顺便再次查阅下官方文档，其建议如下（英文）：

?115,72005,72005

Which would be the more optimzed way to store a boolean, TINYINT(1) or ENUM( 'true' , 'false')? It seems that when storing an enum w/ two settings should only take up one bit, 0 or 1, but would spend more time looking up the enums in the beginning of the query. tinyint(1) however would take up 4 bits assuming it ranged 0-9. So it seems if you just wanted to fetch the value, tinyint(1) would be faster, but if you are searching through lots of records enum('true','false') would be faster. Do you concur??

“翻译”过来（因为本人英语成绩从来就不及格，加上翻译参杂了额外的口水注解，所以把翻译二字加上了双引号）为如下：

TINYINT（1）或ENUM（'真'，'假'）？

      用ENUM存储枚举当存储只有2个值时只占用一个位的宽度，，0或1，但会花更多的时间去寻找了枚举查询的开始。

      用TINYINT（1）默认就会占用4个位的宽度（0000）

      因此得出结论：

      比如要存储一个介于0-9之间的值，为了查询获取这个值，建议用TINYINT（1）会更快，

      但如果你是为了大量记录枚举（“真”，“假”），那么用ENUM( 'true' , 'false') 搜索会更快。

     说起这个ENUM， 经查阅各大技术社区的网络文摘，ENUM确实是mysql里的一个特色字段，印象里模糊记得在以前看到一些比较知名的商城系统如shopnc里面在用它，但也没细究，可能是因为他可以设置字段的区间范围，会让值可以被数据库所控制，有枚举约束的功能（比如，字段只想有0和1，如果用TINYINT（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)，插入的并不是1，而是0。

       另外假如你在设计好enum的枚举字段范围并使用了一段时间后，再到字段范围中加一个枚举值，并且不是加在最后，那么也就相当于把原来的范围都改变了索引值，也就是当你在查询的时候直接查询值（并加上单引号），将不会使用enum自身隐藏的索引值来获取结果了。

        如果是纯数值型，还是建议采用tinyint字段吧，毕竟它也只占一个字节，即使出现赃数据，也可以被接受，不象enum，如果纯数字型范围，更改了索引，你就不知道你查询的值是否正确了）

       故建议，如果字段是字符串，并且长度固定，可以尝试用char，如果是数值型，还是用tinyint吧，比较安全稳定，而且即使迁移，也不会出现太多问题。

       所以为了最终方便，避免出现一些不必要的问题，我在本次商标状态扩张表中仍然按以往习惯使用tinyint哈。

                                                                                                                                 ︶ㄣ. 剑走偏锋 つ

本文出自 “锋哥互联网研究中心” 博客，请务必保留此出处