关于枚举类型
Mysql在存储枚举时会根据列表值的数量压缩到一个或两个字节中，在Mysql内部将每个值在列表的位置保存为整数，且在表的.frm文件中保存形如"数字-字符串"的映射关系表，关于Mysql内部存储的整数会被用来作为进行排序的依据，而不是定义的字符，如果有绕开这种约束的需求，可以使用FIELD（）函数显式地指定顺序，但是也会带来导致Mysql无法利用索引消除排序，所以使用时需要注意场景诉求。
枚举的弊端
枚举的字符串列表是固定的，添加或删除时必须使用ALTER TABLE，对于未来可能会改变的字符串，使用枚举不是好建议，处分能接受在列表的末尾添加元素，即可不必重建整张表来修改。
枚举的优势
因Mysql存储枚举字段时需要进行一次转换相关的映射关系处理，所以导致在用枚举类型时存在性能开销。通过对一张表进行基准测试，会发现将列转换成枚举后，关联速度会看到有明显提升，但是当varchar和enum进行关联时会慢很多，此外转为枚举型还可以让表大小缩小约1/3，所以在非必需要和varchar进行关联操作时，将目标列全部转为枚举是一个比较实惠的做法，即行业内的一条设计实践：
在查找表时，采用整数主键而避免采用基于字符串的值进行关联
至于与varchar列进行关联操作时，转换列为枚举型也是一个节约表大小的思路，关键点在于关联性能与存储空间的取舍，对于InnoDB表，如果表上有其他索引，减小主键大小也会使非主键索引也变得更小。
关于日期、时间类型
Mysql提供多种类型保存日期和时间值，一般情况下Mysql能存储的最小时间粒度为秒（MariaDB支持微秒级别的时间类型），但是也支持使用微秒级的粒度进行临时运算。
Mysql提供两种较为相似的日期类型，DATATIME和TIMESTAMP，相信有些看官会疑问这两个类型该怎么享用才是最佳，在雷记看来这种思维有些属于钻牛角尖，没有太大必要。因为这类时间类型都没有可以替代的选择，不存在最佳选择的问题，与其苦恼选谁，不如一起来了解一下两个类型的大致情况，选出最合适的那一个。
DATETIME
可以保存最大范围的值(由1001年-9999年)，精度为秒，日期和时间封装后的格式为YYYYMMDDHHMMSS的整数，且与时区无关，占用8个字节的存储空间，默认情况下Mysql采用可排序并且无歧义的格式显示DATETIME值，如ANSI标准定义的表示方法"2021-12-10 15:28:00"。
TIMESTAMP
TIMESTAMP采用4个字节的存储空间，范围相比DATETIME要小，只能表示1970年至2038年的描述，起始时间为格林尼治标准时间1970年1月1日午夜，格式为UNIX时间戳，Mysql提供了FROM_UNIXTIME()和UNIX_TIMESTAMP()来进行相互装换。
Mysql4.1之后的版本，按照DATETIME的方式格式化TIMESTAMP的值，TIMESTAMP的存储格式在各个版本是一致的,另外TIMESTAMP依赖于时区，对于时区，可以在Mysql服务器、操作系统os以及客户端连接上设置。在默认情况下，如果插入时未指定第一个TIMESTAMP列的值，Mysql会默认设置为当前时间，在插入一行记录时，Mysql默认也会更新第一个TIMESTAMP列的值，除非在UPDATE语句中明确指定值，我们也可以配置任何TIMESTAMP列的插入和更新行为，需要注意的是TIMESTAP我认为NOT NULL，对于设置TIMESTAMP列之后行为是否符合我们的需要，使用show create table命令检查输出是一个好的选择。
因为TIMESTAMP相对DATETIME存储空间效率高，通常尽量使用TIMESTAMP。另外很多人会将UNIX时间戳存储为整数值，但是并不会带来任何收益，而且对于整数保存时间戳的格式也不方便处理转换，也是不推荐的，建议从Mysql与开发语言的数据类型映射进行选择，采用约定的规则处理。
在需要存储比秒粒度小的日期和时间值，目前Mysql没有合适的数据类型,可以进行自定义的存储格式,比如BIGINT存储微秒级别的时间戳，或者用DOUBLE存储秒之后的小数部分，代码级别进行换算，甚至采用MariaDB也是可以的。
今日份的对于Mysql字符类型分享大致就是这样，若各位看官存有新的工作上学习上的疑问，可以私聊雷记拉入小组一同切磋。因近日来雷记在处理一些关于elk的项目，也整理了若干踩坑填坑经验，届时会和大家一起分享，另外雷记的第一本武侠小说<<天霖流芳>>，也在起点开始连载了，感兴趣的看官可以支持一下，能解终日code的一时倦乏也算得美事一桩。
