麒麟v10 上部署 TiDB v5.1.2 生产环境优化实践
1199
2023-07-01
MySQL数据库怎么实现存储时间
1.切记不要用字符串存储日期
字符串占用的空间更大!
字符串存储的日期比较效率比较低(逐个字符进行比对),无法用日期相关的 API 进行计算和比较。
2.Datetime 和 Timestamp 之间抉择
Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的数据类型。
他们两者究竟该如何选择呢?
通常我们都会首选 Timestamp
2.1 DateTime 类型没有时区信息的
DateTime 类型是没有时区信息的(时区无关)
当你的时区更换之后,比如你的服务器更换地址或者更换客户端连接时区设置的话,就会导致你从数据库中读出的时间错误。
Timestamp 和时区有关。
Timestamp 类型字段的值会随着服务器时区的变化而变化,自动换算成相应的时间,说简单点就是在不同时区,查询到同一个条记录此字段的值会不一样。
下面实际演示一下!
建表 SQL 语句:
CREATE TABLE `time_zone_test` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `date_time` datetime DEFAULT NULL, `time_stamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;登录后复制
插入数据:
INSERT INTO time_zone_test(date_time,time_stamp) VALUES(NOW(),NOW());登录后复制
查看数据:
select dsqlate_time,time_stamp from time_zone_test;登录后复制
结果:
+---------------------+---------------------+| date_time | time_stamp |+---------------------+---------------------+| 2020-01-11 09:53:32 | 2020-01-11 09:53:32 |+---------------------+---------------------+
修改当前会话的时区:
set time_zone='+8:00';登录后复制
再次查看数据:
+---------------------+---------------------+| date_time | time_stamp |+---------------------+---------------------+| 2020-01-11 09:53:32 | 2020-01-11 17:53:32 |+---------------------+---------------------+
扩展: 一些关于 MySQL 时区设置的一个常用 sql 命令
1. 查看当前会话时区
SELECT @@session.time_zone;登录后复制
2. 设置当前会话时区
SET time_zone = 'Europe/Helsinki'; SET time_zone = "+00:00";登录后复制
3. 数据库全局时区设置
SELECT @@global.time_zone;登录后复制
4. 设置全局时区
SET GLOBAL time_zone = '+8:00'; SET GLOBAL time_zone = 'Europe/Helsinki';登录后复制
2.2 DateTime 类型耗费空间更大
Timestamp 只需要使用 4 个字节的存储空间,但是 DateTime 需要耗费 8 个字节的存储空间。然而,这种方法也引发了一个问题,即 Timestamp 的时间范围更为有限。
DateTime :1000-01-01 00:00:00 ~ 9999-12-31 23:59:59Timestamp: 1970-01-01 00:00:01 ~ 2037-12-31 23:59:59
Timestamp 在不同版本的 MySQL 中有细微差别。
3.再看 MySQL 日期类型存储空间
下图是 MySQL 5.6 版本中日期类型所占的存储空间:
可以看出 5.6.4 之后的 MySQL 多出了一个需要 0 ~ 3 字节的小数位。DataTime和Timestamp在存储时会占用不同的存储空间。
为了方便,本文我们还是默认 Timestamp 只需要使用 4 个字节的存储空间,但是 DateTime 需要耗费 8 个字节的存储空间。
4.数值型时间戳是更好的选择吗?
很多时候,我们也会使用 int 或者 bigint 类型的数值也就是时间戳来表示时间。
这种存储方式的具有 Timestamp 类型的所具有一些优点,并且使用它的进行日期排序以及对比等操作的效率会更高,跨系统也很方便,毕竟只是存放的数值。缺点也很明显,就是数据的可读性太差了,你无法直观的看到具体时间。
时间戳的定义如下:
时间戳的定义是从一个基准时间开始算起,这个基准时间是「1970-1-1 00:00:00 +0:00」,从这个时间开始,用整数表示,以秒计时,随着时间的流逝这个时间整数不断增加。这样一来,我只需要一个数值,就可以完美地表示时间了,而且这个数值是一个绝对数值,即无论的身处地球的任何角落,这个表示时间的时间戳,都是一样的,生成的数值都是一样的,并且没有时区的概念,所以在系统的中时间的传输中,都不需要进行额外的转换了,只有在显示给用户的时候,才转换为字符串格式的本地时间。
数据库中实际操作:
mysql> select UNIX_TIMESTAMP('2020-01-11 09:53:32');+---------------------------------------+| UNIX_TIMESTAMP('2020-01-11 09:53:32') |+---------------------------------------+| 1578707612 |+---------------------------------------+1 row in set (0.00 sec)mysql> select FROM_UNIXTIME(1578707612);+---------------------------+| FROM_UNIXTIME(1578707612) |+---------------------------+| 2020-01-11 09:53:32 |+---------------------------+1 row in set (0.01 sec)登录后复制
5.总结
推荐 Timestamp,原因是数值表示时间不够直观
每种方式都有各自的优势,根据实际场景才是王道。下面再对这三种方式做一个简单的对比,以供大家实际开发中选择正确的存放时间的数据类型:
6.设置mysql date类型字段默认值支持0000格式
[mysqld]sql-mode=STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION登录后复制
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。