使用时间戳（或日期时间）作为主键的一部分（或聚集索引的一部分）答案

【问题标题】：Use timestamp(or datetime) as part of primary key (or part of clustered index)使用时间戳（或日期时间）作为主键的一部分（或聚集索引的一部分）
【发布时间】：2013-05-26 21:52:46
【问题描述】：

我经常使用以下查询：

SELECT * FROM table WHERE Timestamp > [SomeTime] AND Timestamp < [SomeOtherTime] and publish = 1 and type = 2 order by Timestamp

我想优化这个查询，我正在考虑将时间戳作为聚集索引的主键的一部分，我认为如果时间戳是主键的一部分，则插入表中的数据会按时间戳字段顺序写入磁盘。此外，我认为这大大改善了我的查询，但不确定这是否会有所帮助。

table has 3-4 million+ rows.
timestamp field never changed.
I use mysql 5.6.11

另一个要点是：如果这是改进我的查询，最好使用时间戳（mysql 5.6 中的 4 字节）或日期时间（mysql 5.6 中的 5 字节）？

【问题讨论】：

标签： mysql sql database-design query-optimization

【解决方案1】：

四百万行并不大。

日期时间和时间戳数据类型之间的一个字节差异是您在这两种数据类型之间进行选择时应该考虑的最后件事。 Review their specs.

制作主键的时间戳部分是一个坏主意。考虑查看主键在 SQL 数据库中的含义。

在您的时间戳列上放置一个索引。获取执行计划，并将其粘贴到您的问题中。确定您的中值查询性能，并将那个粘贴到您的问题中。

从我的台式计算机上的 400 万行索引表中返回一天的行需要 2 毫秒。（它返回大约 8000 行。）

【讨论】：

【解决方案2】：

1) 如果时间戳的值是唯一的，您可以将其设为主键。如果没有，无论如何都要在时间戳列上创建索引，因为您经常在“where”中使用它。

2) 在这里使用 BETWEEN 子句看起来更自然。我建议你使用 TREE 索引（默认索引类型）而不是 HASH。

3) 当时间戳列被索引时，您不需要调用 order by - 它已经排序。（当然，如果您的索引是 TREE 而不是 HASH）。

4) 整数 unix_timestamp 在内存使用方面和性能方面都优于 datetime - 比较日期比比较整数更复杂。

在索引字段上搜索数据需要 O(log(rows)) 树查找。整数的比较是 O(1)，日期的比较是 O(date_string_length)。因此，差异是（查找树的次数）*（差异比较）= O(date_string_length)/O(1))* O(log(rows)) = O(date_string_length)* O(log(rows))

【讨论】：