Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
么么么么木木木
JavaGuide
提交
27671947
J
JavaGuide
项目概览
么么么么木木木
/
JavaGuide
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
J
JavaGuide
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
27671947
编写于
4月 24, 2020
作者:
S
shuang.kou
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
[feat]增加关于数据库中如何存储时间的一点思考
上级
5b82aec1
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
170 addition
and
3 deletion
+170
-3
README.md
README.md
+9
-3
docs/database/关于数据库存储时间的一点思考.md
docs/database/关于数据库存储时间的一点思考.md
+161
-0
未找到文件。
README.md
浏览文件 @
27671947
...
...
@@ -183,13 +183,19 @@ Github用户如果访问速度缓慢的话,可以转移到[码云](https://git
### MySQL
**总结:**
1.
**[【推荐】MySQL/数据库 知识点总结](docs/database/MySQL.md)**
2.
**[阿里巴巴开发手册数据库部分的一些最佳实践](docs/database/阿里巴巴开发手册数据库部分的一些最佳实践.md)**
3.
**[一千行MySQL学习笔记](docs/database/一千行MySQL命令.md)**
4.
[
MySQL高性能优化规范建议
](
docs/database/MySQL高性能优化规范建议.md
)
5.
[
数据库索引总结1
](
docs/database/MySQL%20Index.md
)
、
[
数据库索引总结2
](
docs/database/数据库索引.md
)
6.
[
事务隔离级别(图文详解)
](
docs/database/事务隔离级别(图文详解
)
.md)
7.
[
一条SQL语句在MySQL中如何执行的
](
docs/database/一条sql语句在mysql中如何执行的.md
)
**重要知识点:**
1.
[
数据库索引总结1
](
docs/database/MySQL%20Index.md
)
、
[
数据库索引总结2
](
docs/database/数据库索引.md
)
2.
[
事务隔离级别(图文详解)
](
docs/database/事务隔离级别(图文详解
)
.md)
3.
[
一条SQL语句在MySQL中如何执行的
](
docs/database/一条sql语句在mysql中如何执行的.md
)
4.
**[关于数据库中如何存储时间的一点思考](docs/database/关于数据库存储时间的一点思考.md)**
### Redis
...
...
docs/database/关于数据库存储时间的一点思考.md
0 → 100644
浏览文件 @
27671947
我们平时开发中不可避免的就是要存储时间,比如我们要记录操作表中这条记录的时间、记录转账的交易时间、记录出发时间等等。你会发现这个时间这个东西与我们开发的联系还是非常紧密的,用的好与不好会给我们的业务甚至功能带来很大的影响。所以,我们有必要重新出发,好好认识一下这个东西。
这是一篇短小精悍的文章,仔细阅读一定能学到不少东西!
### 1.切记不要用字符串存储日期
我记得我在大学的时候就这样干过,而且现在很多对数据库不太了解的新手也会这样干,可见,这种存储日期的方式的优点还是有的,就是简单直白,容易上手。
但是,这是不正确的做法,主要会有下面两个问题:
1.
字符串占用的空间更大!
2.
字符串存储的日期比较效率比较低(逐个字符进行比对),无法用日期相关的 API 进行计算和比较。
### 2.Datetime 和 Timestamp 之间抉择
Datetime 和 Timestamp 是 MySQL 提供的两种比较相似的保存时间的数据类型。他们两者究竟该如何选择呢?
**通常我们都会首选 Timestamp。**
下面说一下为什么这样做!
#### 2.1 DateTime 类型没有时区信息的
**DateTime 类型是没有时区信息的(时区无关)**
,DateTime 类型保存的时间都是当前会话所设置的时区对应的时间。这样就会有什么问题呢?当你的时区更换之后,比如你的服务器更换地址或者更换客户端连接时区设置的话,就会导致你从数据库中读出的时间错误。不要小看这个问题,很多系统就是因为这个问题闹出了很多笑话。
**Timestamp 和时区有关**
。Timestamp 类型字段的值会随着服务器时区的变化而变化,自动换算成相应的时间,说简单点就是在不同时区,查询到同一个条记录此字段的值会不一样。
下面实际演示一下!
建表 SQL 语句:
```
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
;
```
插入数据:
```
sql
INSERT
INTO
time_zone_test
(
date_time
,
time_stamp
)
VALUES
(
NOW
(),
NOW
());
```
查看数据:
```
sql
select
date_time
,
time_stamp
from
time_zone_test
;
```
结果:
```
+---------------------+---------------------+
| date_time | time_stamp |
+---------------------+---------------------+
| 2020-01-11 09:53:32 | 2020-01-11 09:53:32 |
+---------------------+---------------------+
```
现在我们运行
修改当前会话的时区:
```
sql
set
time_zone
=
'+8:00'
;
```
再次查看数据:
```
+---------------------+---------------------+
| date_time | time_stamp |
+---------------------+---------------------+
| 2020-01-11 09:53:32 | 2020-01-11 17:53:32 |
+---------------------+---------------------+
```
**扩展:一些关于 MySQL 时区设置的一个常用 sql 命令**
```
sql
#
查看当前会话时区
SELECT
@@
session
.
time_zone
;
#
设置当前会话时区
SET
time_zone
=
'Europe/Helsinki'
;
SET
time_zone
=
"+00:00"
;
#
数据库全局时区设置
SELECT
@@
global
.
time_zone
;
#
设置全局时区
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:59
-
Timestamp: 1970-01-01 00:00:01 ~ 2037-12-31 23:59:59
> Timestamp 在不同版本的 MySQL 中有细微差别。
### 3 再看 MySQL 日期类型存储空间
下图是 MySQL 5.6 版本中日期类型所占的存储空间:
![](
https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/FhRGUVHFK0ujRPNA75f6CuOXQHTE.jpeg
)
可以看出 5.6.4 之后的 MySQL 多出了一个需要 0 ~ 3 字节的小数位。Datatime 和 Timestamp 会有几种不同的存储空间占用。
为了方便,本文我们还是默认 Timestamp 只需要使用 4 个字节的存储空间,但是 DateTime 需要耗费 8 个字节的存储空间。
### 4.数值型时间戳是更好的选择吗?
很多时候,我们也会使用 int 或者 bigint 类型的数值也就是时间戳来表示时间。
这种存储方式的具有 Timestamp 类型的所具有一些优点,并且使用它的进行日期排序以及对比等操作的效率会更高,跨系统也很方便,毕竟只是存放的数值。缺点也很明显,就是数据的可读性太差了,你无法直观的看到具体时间。
时间戳的定义如下:
> 时间戳的定义是从一个基准时间开始算起,这个基准时间是「1970-1-1 00:00:00 +0:00」,从这个时间开始,用整数表示,以秒计时,随着时间的流逝这个时间整数不断增加。这样一来,我只需要一个数值,就可以完美地表示时间了,而且这个数值是一个绝对数值,即无论的身处地球的任何角落,这个表示时间的时间戳,都是一样的,生成的数值都是一样的,并且没有时区的概念,所以在系统的中时间的传输中,都不需要进行额外的转换了,只有在显示给用户的时候,才转换为字符串格式的本地时间。
数据库中实际操作:
```
sql
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.总结
MySQL 中时间到底怎么存储才好?Datetime?Timestamp? 数值保存的时间戳?
好像并没有一个银弹,很多程序员会觉得数值型时间戳是真的好,效率又高还各种兼容,但是很多人又觉得它表现的不够直观。这里插一嘴,《高性能 MySQL 》这本神书的作者就是推荐 Timestamp,原因是数值表示时间不够直观。下面是原文:
<img
src=
"https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/高性能mysql-不推荐用数值时间戳.jpg"
style=
"zoom:50%;"
/>
每种方式都有各自的优势,根据实际场景才是王道。下面再对这三种方式做一个简单的对比,以供大家实际开发中选择正确的存放时间的数据类型:
<img
src=
"https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/总结-常用日期存储方式.jpg"
style=
"zoom:50%;"
/>
如果还有什么问题欢迎给我留言!如果文章有什么问题的话,也劳烦指出,Guide 哥感激不尽!
后面的文章我会介绍:
-
[ ] Java8 对日期的支持以及为啥不能用 SimpleDateFormat。
-
[ ] SpringBoot 中如何实际使用(JPA 为例)
\ No newline at end of file
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录