濮阳杆衣贸易有限公司

主頁 > 知識(shí)庫 > MySQL存儲(chǔ)時(shí)間類型選擇的問題講解

MySQL存儲(chǔ)時(shí)間類型選擇的問題講解

熱門標(biāo)簽:電銷機(jī)器人各個(gè)細(xì)節(jié)介紹 昆明電信400電話辦理 電銷機(jī)器人 行業(yè) 俄國(guó)地圖標(biāo)注app 溫州瑞安400電話怎么申請(qǐng) 電話機(jī)器人市場(chǎng)趨勢(shì) 南昌高頻外呼系統(tǒng)哪家公司做的好 百度地圖標(biāo)注后不顯示 淄博400電話申請(qǐng)

MySQL中存儲(chǔ)時(shí)間通常會(huì)用datetime類型,但現(xiàn)在很多系統(tǒng)也用int存儲(chǔ)unix時(shí)間戳,它們有什么區(qū)別?本人總結(jié)如下:

int

(1)4個(gè)字節(jié)存儲(chǔ),INT的長(zhǎng)度是4個(gè)字節(jié),存儲(chǔ)空間上比datatime少,int索引存儲(chǔ)空間也相對(duì)較小,排序和查詢效率相對(duì)較高一點(diǎn)點(diǎn)

(2)可讀性極差,無法直觀的看到數(shù)據(jù)

TIMESTAMP

(1)4個(gè)字節(jié)儲(chǔ)存

(2)值以UTC格式保存

(3)時(shí)區(qū)轉(zhuǎn)化 ,存儲(chǔ)時(shí)對(duì)當(dāng)前的時(shí)區(qū)進(jìn)行轉(zhuǎn)換,檢索時(shí)再轉(zhuǎn)換回當(dāng)前的時(shí)區(qū)。

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

datetime

(1)8個(gè)字節(jié)儲(chǔ)存

(2)與時(shí)區(qū)無關(guān)

(3)以'YYYY-MM-DD HH:MM:SS'格式檢索和顯示DATETIME值。支持的范圍為'1000-01-01 00:00:00'到'9999-12-31 23:59:59'

隨著Mysql性能越來越來高,個(gè)人覺得關(guān)于時(shí)間的存儲(chǔ)方式,具體怎么存儲(chǔ)看個(gè)人習(xí)慣和項(xiàng)目需求吧

分享兩篇關(guān)于int vs timestamp vs datetime性能測(cè)試的文章

Myisam:MySQL DATETIME vs TIMESTAMP vs INT 測(cè)試儀

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

機(jī)型配置

  • 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

測(cè)試

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

執(zhí)行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_timest
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

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接

您可能感興趣的文章:
  • MySQL 時(shí)間類型的選擇
  • 如何選擇合適的MySQL日期時(shí)間類型來存儲(chǔ)你的時(shí)間
  • 關(guān)于mysql 的時(shí)間類型選擇
  • 解析MySql與Java的時(shí)間類型
  • MySQL日期數(shù)據(jù)類型、時(shí)間類型使用總結(jié)
  • MySQL時(shí)間類型和模式詳情

標(biāo)簽:吐魯番 安徽 洛陽 拉薩 葫蘆島 甘南 嘉峪關(guān) 巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《MySQL存儲(chǔ)時(shí)間類型選擇的問題講解》,本文關(guān)鍵詞  MySQL,存儲(chǔ),時(shí)間,類型,選擇,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。

  • 相關(guān)文章
  • 下面列出與本文章《MySQL存儲(chǔ)時(shí)間類型選擇的問題講解》相關(guān)的同類信息!
  • 本頁收集關(guān)于MySQL存儲(chǔ)時(shí)間類型選擇的問題講解的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章
    张北县| 从化市| 铁岭县| 南漳县| 若尔盖县| 萝北县| 刚察县| 顺平县| 江城| 丰都县| 扬中市| 民乐县| 商丘市| 元江| 双城市| 咸阳市| 平顺县| 高州市| 临漳县| 沛县| 阳新县| 贵州省| 烟台市| 澄江县| 名山县| 金昌市| 安仁县| 荔浦县| 郴州市| 玉山县| 鹿泉市| 涿鹿县| 白水县| 汝城县| 阿拉善盟| 兴隆县| 峨边| 富顺县| 迭部县| 呼图壁县| 龙口市|