在线精品99_中国九九盗摄偷拍偷看_91免费版在线观看_91.app_91高清视频在线_99热最新网站

如何解决MySQL存储时间类型选择的问题

114次阅读
没有评论

共计 3848 个字符,预计需要花费 10 分钟才能阅读完成。

这篇文章主要为大家展示了“如何解决 MySQL 存储时间类型选择的问题”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让丸趣 TV 小编带领大家一起研究并学习一下“如何解决 MySQL 存储时间类型选择的问题”这篇文章吧。

MySQL 中存储时间通常会用 datetime 类型,但现在很多系统也用 int 存储 unix 时间戳,它们有什么区别?本人总结如下:

int

(1)4 个字节存储,INT 的长度是 4 个字节,存储空间上比 datatime 少,int 索引存储空间也相对较小,排序和查询效率相对较高一点点

(2)可读性极差,无法直观的看到数据

TIMESTAMP

(1)4 个字节储存

(2)值以 UTC 格式保存

(3)时区转化,存储时对当前的时区进行转换,检索时再转换回当前的时区。

(4)TIMESTAMP 值不能早于 1970 或晚于 2037

datetime

(1)8 个字节储存

(2)与时区无关

(3)以 YYYY-MM-DD HH:MM:SS 格式检索和显示 DATETIME 值。支持的范围为 1000-01-01 00:00:00 到 9999-12-31 23:59:59

随着 Mysql 性能越来越来高,个人觉得关于时间的存储方式,具体怎么存储看个人习惯和项目需求吧

分享两篇关于 int vs timestamp vs datetime 性能测试的文章

Myisam:MySQL DATETIME vs TIMESTAMP vs INT 测试仪

CREATE TABLE `test_datetime` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`datetime` FIELDTYPE NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM;

机型配置

kip-locking

key_buffer = 128M

max_allowed_packet = 1M

table_cache = 512

sort_buffer_size = 2M

read_buffer_size = 2M

read_rnd_buffer_size = 8M

myisam_sort_buffer_size = 8M

thread_cache_size = 8

query_cache_type = 0

query_cache_size = 0

thread_concurrency = 4

测试

DATETIME  14111 14010  14369  130000000
TIMESTAMP  13888  13887  14122  90000000
INT  13270  12970  13496  90000000

执行 mysql

mysql  select * from test_datetime into outfile ‘/tmp/test_datetime.sql 
Query OK, 10000000 rows affected (6.19 sec)
mysql  select * from test_timestamp into outfile ‘/tmp/test_timestamp.sql 
Query OK, 10000000 rows affected (8.75 sec)
mysql  select * from test_int into outfile ‘/tmp/test_int.sql 
Query OK, 10000000 rows affected (4.29 sec)
alter table test_datetime rename test_int;
alter table test_int add column datetimeint INT NOT NULL;
update test_int set datetimeint = UNIX_TIMESTAMP(datetime);
alter table test_int drop column datetime;
alter table test_int change column datetimeint datetime int not null;
select * from test_int into outfile ‘/tmp/test_int2.sql 
drop table test_int;

So now I have exactly the same timestamps from the DATETIME test, and it will be possible to reuse the originals for TIMESTAMP tests as well.

mysql load data infile‘/export/home/ntavares/test_datetime.sql into table test_datetime;
Query OK, 10000000 rows affected (41.52 sec)
Records: 10000000 Deleted: 0 Skipped: 0 Warnings: 0

mysql load data infile‘/export/home/ntavares/test_datetime.sql into table test_timestamp;
Query OK, 10000000 rows affected, 44 warnings (48.32 sec)
Records: 10000000 Deleted: 0 Skipped: 0 Warnings: 44

mysql load data infile‘/export/home/ntavares/test_int2.sql into table test_int;
Query OK, 10000000 rows affected (37.73 sec)
Records: 10000000 Deleted: 0 Skipped: 0 Warnings: 0

As expected, since INT is simply stored as is while the others have to be recalculated. Notice how TIMESTAMP still performs worse, even though uses half of DATETIME storage size.

Let s check the performance of full table scan:

mysql  SELECT SQL_NO_CACHE count(id) FROM test_datetime WHERE datetime   ‘1970-01-01 01:30:00′ AND datetime   ‘1970-01-01 01:35:00′;
+———–+
| count(id) |
+———–+
| 211991 |
+———–+
1 row in set (3.93 sec)
mysql  SELECT SQL_NO_CACHE count(id) FROM test_timestamp WHERE datetime   ‘1970-01-01 01:30:00′ AND datetime   ‘1970-01-01 01:35:00′;
+———–+
| count(id) |
+———–+
| 211991 |
+———–+
1 row in set (9.87 sec)
mysql  SELECT SQL_NO_CACHE count(id) FROM test_int WHERE datetime   UNIX_TIMESTAMP(1970-01-01 01:30:00′) AND datetime   UNIX_TIMESTAMP(1970-01-01 01:35:00′);
+———–+
| count(id) |
+———–+
| 211991 |
+———–+
1 row in set (15.12 sec)

Then again, TIMESTAMP performs worse and the recalculations seemed to impact, so the next good thing to test seemed to be without those recalculations: find the equivalents of those UNIX_TIMESTAMP() values, and use them instead:

mysql  select UNIX_TIMESTAMP(1970-01-01 01:30:00′) AS lower, UNIX_TIMESTAMP(1970-01-01 01:35:00′) AS bigger;
+——-+——–+
| lower | bigger |
+——-+——–+
| 1800 | 2100 |
+——-+——–+
1 row in set (0.00 sec)
mysql  SELECT SQL_NO_CACHE count(id) FROM test_int WHERE datetime   1800 AND datetime   2100;
+———–+
| count(id) |
+———–+
| 211991 |
+———–+
1 row in set (1.94 sec)

Innodb:MySQL DATETIME vs TIMESTAMP vs INT performance and benchmarking with InnoDB

以上是“如何解决 MySQL 存储时间类型选择的问题”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注丸趣 TV 行业资讯频道!

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-04发表,共计3848字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)
主站蜘蛛池模板: 激情内射亚州一区二区三区爱妻 | 精品久久久无码中文字幕天天 | 国产亚洲一级精品久久 | 一一级毛片 | 国产老妇伦国产熟女老妇视频 | 综合欧美日韩一区二区三区 | 国产av无码专区亚洲a∨毛片 | 婷婷人人爽人人做人人添 | 久久久久久久久久久福利 | 午夜福利1000集在线观看 | 色欲久久久天天天综合网 | 8050午夜一级全黄毛片 | 99热这里只有精品首页 | 欧美在线综合视频 | 99re热这里只有精品视频 | 伊人网综合 | 免费搞黄网站 | 亚洲国产精品免费观看 | 欧美一区二区三区国产精品 | 成人黄色在线观看视频 | 中文字幕无码家庭乱欲 | 午夜色大片在线观看 | 日本一级特黄aa毛片免费观看 | 国产成人av一区二区三区 | 国产精品久久久久9999无码 | 少女高清影视在线观看动漫 | 国产尤物在线播放 | 亚洲av无码专区国产乱码不卡 | 精品无人区乱码麻豆1区2区 | 免费国产高清视频 | 黑丝在线免费观看 | 欧美午夜特黄aaaaaa片 | 中文字幕高清av在线 | 一个人免费观看www视频在线 | 99高清免费国产自产拍 | 欧美日韩中文国产一区二区三区 | 久久精品国产精品青草色艺 | 亚洲在线看片 | 亚洲欧美成人久久综合中文网 | 一级大片免费观看 | 2019精品国产品免费观看 |