首页天道酬勤mysql修改表字段(mysql改字段类型流程)

mysql修改表字段(mysql改字段类型流程)

张世龙 12-18 23:55 134次浏览

MySQL存储日期的数据类型为日期、时间、年、日期和时间戳。

这里主要讨论YYYY-MM-DD HH:MM:SS格式的时间。 因为这个用得最多。 关于其他格式采用的数据类型的讨论,也大致同样适用,但在此不作说明。

存储YYYY-MM-DD HH:MM:SS格式的数据类型有DATETIME和TIMESTAMP,但INT类型严格来说只是存储数字,与时间无关。 由于只是人为地视为时间戳,所以在实际操作中需要使用一些方法转换为真正的日期格式。 也有BIGINT型。 这与INT类型相同,但占用空间大,可显示的时间范围也大。 但是,我在实际的开发中没有遇到过。 我的经历可能还很浅。 这里,由于空间的限制,不讨论BIGINT。

关于这个问题网上的讨论其实有很多,我根据自己的经验把它们总结如下表。

可以看出,不同的数据类型有各自的特点。 让我们具体分析一下各自的特点。

存储空间

存储空间中,DATETIME的存储空间是其他类型的两倍,但实际上增加了4个字节。 现在的系统越来越复杂,很多表的字段往往从十几行变成几十行,这四个字节以上实际上没有任何影响,可以完全忽略。 除非表中的所有字段都是日期类型,否则必须进行测量。

显示格式

INT类型需要通过MySQL提供的函数或程序本身添加处理,以我们希望的日期格式显示,但实际上也不需要太多工作量。 当然,如果直接使用工具连接到数据库进行显示,则可能很难读取INT数据。 在实际工作中,通常禁止使用图形工具直接连接生产数据库。 我们要么写脚本,要么在后台看,这可以在程序处理时把数据转换成我们想要的格式,所以INT数据不能直接读取的缺点对现实影响不大。

操作效率

INT在排序和查询时效率最高,但很少。 如果存在大量查询和排序,添加索引可能会完全解决。 否则,将拆分表或添加缓存。 如果只选择INT,只是自身的处理性能比其他的高,要得到较大的性能提高是不现实的。

跨时区

DATETIME与时区无关,但是可以通过转换为时间戳将时间戳转换为其他时区时间。 方法总是比困难多。

特殊功能

TIMESTAMP可以自动管理时间的更新,确实很方便。

现在的许多框架都有自动管理时间的功能,不一定需要使用TIMESTAMP。

我认为

时间范围

是差别最大的,是我们需要选择的地方。

在这四种数据类型中,TIMESTAMP和INT (无符号)在时间范围上最多只支持到2038年。 也就是说,到了2038年,我们可能会遇到类似千年虫的问题。 面对这个问题,可能有人会不加思考直接选择DATETIME或INT (有符号)。 如果你选择了INT (带符号),问题其实并没有解决。 将MySQL提供的时间戳转换为日期格式的函数FROM_UNIXTIME只支持32个数据,该函数会溢出并返回空值。

那么,直接使用几种编程语言附带的时间处理函数来旋转不就没有这个问题了吗?

当然这没问题。 但是,在结果输出之前,可能需要进行扫描以变换结果。 此外,并非所有语言都能完全正确地处理这个问题。 这个只有实际测试一下才能知道,但我想很多人没有做这个测试。 另外,在设置表时,可能会忘记选中“无符号”选项。

这样的话,我认为只有DATETIME是最安全的。 是的,这也是我推荐的。

综上所述,你可能认为DATETIME是唯一的选择。 不,在现实生活中,我们面临的问题实在太多了,这个问题的重要性在所有问题中几乎等于零。 无论选哪个,从短期来看,都没有太大不同。 关于2038年可能面临的千年虫问题,也没有我们想象的那么可怕。 请考虑一下。 解决千年虫可能需要几十亿,但如果现在解决的话,可能不止这几十亿(思维成本、测试成本等)。 到2038年,很多公司可能倒闭了,那不是很忙的工作吗? 所以完全没有必要在意这个问题。

对一家公司来说,最重要的是如何在激烈的竞争中生存,MySQL的时间字段使用int、datetime还是timestamp? 这个问题对竞争没有任何帮助。 有些人可能会说:“细节决定成败”。 我以前也信奉这句话。 而且凡事都以此为基准。 结果,工作会比别人晚,会把简单的问题想得太复杂。

这个世界

界其实很复杂,许多道理并非一句话就能概括,凡事还是要根据不同场景对症下药。细节用在刀刃上,将事半功倍,要是用在可有可无的地方,那不过是瞎忙活,白费力气。

当然最后还是要做出选择的,咱也不能直接丢骰子随便乱选吧,那就是真的是不负责任了。

下面我根据自己的一些经验给出一些自己的观点。

1、我们到一个公司上班,都不是一开始就从零构建一个项目,一般都是先从维护旧项目开始。在对旧项目添加或者修改功能时,我们可以直接按照该公司的习惯来选择存储时间字段的数据类型。前人用 DATETIME 我们就用 DATETIME,用 INT 我们就用 INT,除非公司有特别指定某种类型。而新项目我也是建议按照之前的设计,减少交接成本。

2、对于自己的个人作品,比如说开源项目,我是建议用 DATETIME,因为我们可以直接连接数据库,格式化的时间看起来多舒服呀。另外,咱们自己维护的项目,自然是想着永远存在的。你想想,十几年后,等孩子长大了,某一天来了兴致要给孩子炫耀一下老爹当年的项目,一打开网站竟然报错,原因是数据溢出,那多尴尬呀!然后你只能说稍等改一下。都一把年纪了,代码也不知道改不改得动。

许多时候,我都会在一些细节问题上纠结。

编程是一门艺术 真是说得太对了。

本文说这么多,更多的是想表达解决问题的思考方法,还有就是在细节的思考上,要先想想有没有那个必要,当然如果只是个人兴趣的话其实没什么所谓。

总算是写完了,太久没写了都生疏了,花了差不多半天时间。

写作不易,如果您喜欢或者觉得有收获,请点个赞,不胜感激。

另外如果您觉得有什么不对的地方,也欢迎评论留言。

初等函数大数据迭代计算
mysql日志文件在哪(mysql怎么存文件) thanx(npm详解)
相关内容