MySql时间类型普查

上文中我们研究了《阿里巴巴开发手册》

传送门：Python 之 MySql“未解之谜”03--悲剧！一道面试题丢失了offer

摘录：

●【强制】表必备三字段：

id, gmt_create, gmt_modified

说明：其中 id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。gmt_create, gmt_modified 的类型均为 datetime 类型，前者现在时表示主动创建，后者过去分词表示被动更新

我想80%公司的开发人员不会在每张表中增加2个字段用来保存时间

在实际工作中

如果我们表中只有一个创建时间，会有哪些弊端呢？

● 某些表中有字段表示状态，状态是会发生变更的，如果没有更新时间，后续状态异常，开发人员在定位问题的时候，会有阻力

● 有些业务场景需要根据更新时间排序，创建时间可能会导致数据排序混乱

● 如果中途添加更新时间，不得不处理历史遗留数据

建议：MySql中至少维护2个时间字段（更新时间和创建时间）

也许你创建的表将影响下一看到的开发者

形成一个良性循环

时间格式为什么推荐 datetime 类型，它与 MySql 中其他类型有什么区别呢？

表1

● 不同的时间类型字节大小确定，故我们在使用时可以不设置长度

● 不同的时间类型都有一个取值范围

重点说下DATETIME和TIMESTAMP，格式一样，但是DATETIME的取值范围大于TIMESTAMP，其中的1970是格林威治时间，我们常见的时间戳就是从这个起点开始计算的。

如果你的表字段使用了TIMESTAMP，会出现一个神奇的现象：

明明设置的时间在 TIMESTAMP 范围内，竟然报错了

原来 MySQL 在存储的时候会将 timestamp 类型的字段从当前时区转成 UTC 时区，需要减去 8 小时，所以最后 1970-01-01 08:00:00 这个时间存储到 MySQL 其实变成了 1970-01-01 00:00:00，不在 timestamp 类型的范围内了

当我换成 1970-01-01 08:00:01 ，就顺利保存了

● 表1中的零值表示的是在非严格模式当超过取值范围是使用零值

● 如果对时分秒没有要求，可以使用DATE，比如身份证有效期

● 如果只统计年份，可以使用YEAR，比如说人口普查年份

● 如果是时分秒，可以使用TIME，比如某些苦逼的程序猿上班时间是

09:00:00 ~ 21:00:00

目前使用最多的还是 DateTime，在前端页面展示的时候我们可以格式化，实现不同的效果

如果一万年以后，时间格式范围都失效了，会发生什么？看看谁的脑洞更大？

我先来

MySql 已经 game over 啦

长江后浪拍前浪，MySql die在沙滩上

>>>Python 之 MySql“未解之谜”05--表示金钱的用什么类型？