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

在以往的经验中,如果遇到需要抉择是否用mysqlenum数据类型时,我基本不用思考的就会放弃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。

无阶未来模型擂台/AI 应用平台 无阶未来模型擂台/AI 应用平台

无阶未来模型擂台/AI 应用平台,一站式模型+应用平台

无阶未来模型擂台/AI 应用平台 35 查看详情 无阶未来模型擂台/AI 应用平台

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

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

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

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

                                                                                                                                 ︶ㄣ. 剑走偏锋 つ

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

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 chuangxiangniao@163.com 举报,一经查实,本站将立刻删除。
发布者:程序猿,转转请注明出处:https://www.chuangxiangniao.com/p/560422.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2025年11月10日 00:45:19
下一篇 2025年11月10日 00:49:22

相关推荐

发表回复

登录后才能评论
关注微信