为什么辣么多人喜欢用 tinyint 而不用 enum？

能实现就行，干嘛纠结

你见过所有字段全用 varchar 的嘛,id,时间啥的全是 varchar

unsigned 不算强迫症，可以考虑改过来。

enum 移植性不如 tinyint 。

enum 后期修改维护什么的坑多。大部分人对这个都没有足够经验。规避风险还是用 tinyint 吧。

我们公司就 type status 之类的字段使用 "0 1 2 3 4 5" 来代表,统一使用枚举

可扩展性

@yongzhong 艾玛，我感觉存时间戳挺好用的 varchar (20)， mysql 预设的感觉都不好用。

enum 坑大啊，查 sql 要写上引号，否则查询不了？

全用 text 路过

@Felldeadbird hibernate 的话能自动处理

为了兼容性。
你用了一堆 enum 要是回头说转到 postgresql 玩了难道整个系统返修一遍么……
（而且像 Rails 什么的早就支持在框架内自动映射数字到枚举了。

当你某天 BOSS 告诉你我们要在男和女之外增加一个『保密』时你就会觉得 enum 不如 tinyint 了。。。
（神马？保密就让值为 null ？那再加一个『人妖』好了


enum 在 alter table 时的开销巨大。哪怕你只是新增一个值， mysql （ 5.6 及 5.6 之前，因为我没研究过 5.7 ）依然会重建整个表_(:з」∠)_

@kslr 时间戳不是应该 unsigned int 么 如果考虑到整型溢出的问题 unsigned bitint 就够了啊 这才 4 字节，你那 varchar 就 20 字节了

@realpg int 存时间可读性差呀，每次查询出来都要记得用内置函数转换下。另外如果时间需要精确到毫秒的呢？

看上面全用 text 或 varchar 的，只能说现在的年轻人啊，太浮躁了，学习一点关系型数据库知识有好处的。

enum 经常用啊

@littlehz
没觉得可读性差啊 脑袋自带粗略转换功能
需要的话，毫秒时间戳也不是不行啊。

而且，从来没觉得有很多需要去数据库的界面直读时间串的，在任何程序界面都很好转换成可读的。

部分调试、维护场景，可以头脑粗略转换

@realpg 当然不是说时间用 varchar 存，个人不喜欢用 int 存。 mysql 自己的 datetime 就不错，显示成字符串，存储占 8 字节。

@kslr
用 varchar 存时间戳，当某条数据早于 2001/9/9 9:46:40 的时候排序会遇到问题。


@littlehz
如果这时候有个只显示年月日这种需求，转换起来可能没那么方便。

我觉得还是迁移问题吧

我记得我用 bigint 存的时间戳，输出的时候爱怎么转换怎么转换。

移植和迁移

看来我一直用 enum 和 unsigned 没什么好处…… 还好现在开始用 sqlalchemy 不用考虑这些了

这和时间用 bigint 存而不用 date 或者 timestamp 是一个道理

说个邪恶的理由吧, 也许性别有一天变的不止男女, 至于 type/status 之类的字段 变化的可能性会更高

我会说我用 char(2)来做么，是，否。。。。

Facebook 包含了 56 种非传统性别
http://www.guokr.com/article/438003/
如果哪天老板想不开也想跟国际接轨的话，画面还是比较美的。

曾经有个知乎段子：大意是说有个字段原本只有两种可能的值，开始时候偷懒就 true/false 了，后来需求改了，这个字段可能有三种值了。。。

用 mysql 的 enum 代替字符型的值是蛮好的，排序似乎不怎么方便吧；对于 tinyint 的列，你用 enum 来枚举值不会混乱么？而且 tinyint 占用的空间也不大，对于开发来说用 tinyint 还是比较愉快的

至于数据类型的问题， mysql 执行的建表语句，并不是你输入什么就给你执行什么， mysql 会帮你优化数据类型后再建表（ mysql 认为你定义的数据类型不够好，会自动帮你换掉的， innodb 下可以试试看），你可以用"show create table 表名 "看看你实际创建表的语句

Hibernate 默认是 自动转 int ，按声明顺序

然各料都用很久了，最後都主流料都能互相移的位，又因 SQLite 有位，又遇到跨主同步，位乾脆用浮位存 utc 秒，小存毫秒，毫秒都小差就是，

tinyint 的性能和 enum 差不多，用 tinyint ，程序更容易扩展，所以一般需要用枚举的字段，我全部用 tinyint