【问题标题】:Timestamp vs datetime vs int - with and without indexes - testsTimestamp vs datetime vs int - 有和没有索引 - 测试
【发布时间】:2013-02-17 13:06:23
【问题描述】:

就我而言,我只会测试哪种日期时间格式最适合我的查询持续时间。这是我的查询:

   SELECT 
    max(ColumnA), -- bigint
    CreateDate, 
    ColumnB, 
    EndTime, 
    ColumnC, 
    ColumnD, 
    ColumnE, 
    ColumnF, -- int
    StartTime, -- timestamp or datetime or int - UNIX_TIMESTAMP(StartTime)
    ColumnG, 
    ColumnH, 
    ColumnI, 
    ColumnJ, 
    UpdateDate, 
    ColumnK FROM TABLE

条件:

-- with indexes
  (Iteration 1) WHERE StartTime BETWEEN "2013-01-18 16:50:00" AND "2013-10-18 18:05:00" AND ColumnF in(5428) GROUP BY ColumnF,StartTime
  (Iteration 2) WHERE StartTime BETWEEN "2013-05-18 11:00:00" AND "2013-06-23 22:05:00" AND ColumnF in(5428) GROUP BY ColumnF,StartTime
  (Iteration 3) WHERE StartTime BETWEEN "2013-08-18 11:00:00" AND "2013-08-23 22:05:00" AND ColumnF in(7752) GROUP BY ColumnF,StartTime
  (Iteration 4) WHERE StartTime BETWEEN "2013-01-18 16:50:00" AND "2013-10-18 18:05:00" AND ColumnF in(5428,5675,444) GROUP BY ColumnF,StartTime
  (Iteration 5) WHERE StartTime BETWEEN "2013-09-01 16:50:00" AND "2013-09-15 18:05:00" AND ColumnF in(5428,5675,444) GROUP BY ColumnF,StartTime
-- and same without indexes

测试信息:

Count = 400K
Engine version = 5.6.10
DBEngine = InnoDB
Tests procedure - MySQL restart before any query.

结果:

With index on StartTime, with index on ColumnF                      

    Iteration   1      2       3       4       5
timestamp   0.094   0.094   0.124   0.124   0.125
datetime    0.125   0.109   0.141   0.156   0.156
int         0.125   0.124   0.094   0.156   0.156
Rows            38     8       1       128  8

Without index on StartTime, with index on ColumnF                   
    Iteration   1      2       3       4      5
timestamp   0.078   0.062   0.062   0.109   0.125
datetime    0.078   0.078   0.078   0.140   0.125
int         0.078   0.078   0.078   0.140   0.125
Rows            38     8       1       128      8

所以我决定使用不带索引的时间戳(但不带索引的结果看起来很相似)。

编辑: 我真的不知道为什么我决定只使用一个查询。也许是懒惰,也许我不应该在星期天工作:) 现在测试无关紧要,结论是错误的。当我进行测试时,我会重写所有测试信息......通常:)

编辑2: 固定

【问题讨论】:

  • Kot,你可以试试ColumnF = 5428 看看它是否改变了什么?它是什么版本的 MySQL?
  • @DoSparKot 当然,如果您需要,我可以尝试。给我更多的时间:)

标签: mysql performance datetime timestamp


【解决方案1】:

有一天我问了一个关于when we chose Datetime over Timestamp的问题。我认为你不会用整数时间戳赢得很多时间。 另外,请记住 TIMESTAMPDATETIME 在 MySQL 中是别名,如果你使用 PostgreSQL,你将只有 TIMESTAMP。所以在这里,你的测试似乎无关紧要。

EDIT :它们等效。它们的格式相同。事实上Timestamp 只是一个时区不敏感类型。它让你摆脱这件事。但它会减少自定义,并且限制在 1970 年到 2038 年。如果您有其他日期要存储(更早或更晚),您将失败。

有两件事让我这么说:

  • 两次迭代
  • 没有分散度量
  • 您正在测试的所有内容几乎没有区别

INTTIMESTAMP 的最大区别在于内存中的位置。你不测试它。观察到的时间跨度真的很短。

我想你猜我完全赞成 DateTime 而不是整数。

【讨论】:

  • DATETIME supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59' and TIMESTAMP has a range of '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC. MAXDB SQL 模式除外。
  • 已编辑。抱歉这个错误,我误读了文档并依赖于它们都显示的格式。
  • 感谢您的快速回答。在我的情况下,我只会测试哪种日期时间格式最适合我的查询持续时间(也许我应该早点写)。在那种情况下(我知道我测试了非常相似的日期类型)没有索引的时间戳比任何其他类型都快 - 我认为这很有趣。所以 - 在这种情况下 - 我应该使用没有索引的时间戳(如果时间戳范围不小)列 - 这是我的结论。
  • 它并不是真的更快。此外,您只是没有足够的时间迭代测试来获取真实数据。当你坐在板凳上时,你正在做统计数据。你不能只从一组数据中推断出一些东西。
  • @artragis 你说得对,我真的不知道为什么我决定只使用一个查询。也许是懒惰,也许我不应该在星期天工作:) 现在测试无关紧要,结论是错误的。谢谢!
猜你喜欢
  • 2016-12-05
  • 1970-01-01
  • 1970-01-01
  • 2020-09-05
  • 2016-07-21
  • 1970-01-01
  • 2011-09-22
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多