在时间戳上创建索引以优化查询

Question

我有以下形式的查询：

SELECT * FROM MyTable WHERE Timestamp > [SomeTime] AND Timestamp < [SomeOtherTime]

我想优化这个查询，我正在考虑在时间戳上放置一个索引，但不确定这是否有帮助。理想情况下，我想让时间戳成为聚集索引，但 MySQL 不支持聚集索引，除了主键。

• MyTable 有超过 400 万行。
• Timestamp 实际上是 INT 类型。
• 一旦插入一行，就永远不会改变。
• 任何给定Timestamp 的行数平均约为 20，但可能高达 200。
• 新插入的行的Timestamp 大于大多数现有行，但可能小于某些最近的行。

Timestamp 上的索引能否帮助我优化此查询？

Answer 1

对此毫无疑问。如果没有索引，您的查询必须查看表中的每一行。使用索引，就定位正确的行而言，查询几乎是即时的。您将付出的代价是插入的性能轻微下降；但这真的很轻微。

Answer 2

您绝对应该使用索引。 MySQL 不知道这些时间戳的顺序，为了找到给定时间戳（或时间戳范围）的记录，它需要查看每条记录。有 400 万个，那是相当多的时间！索引是你告诉 MySQL 你的数据的方式——“我会经常查看这个字段，所以请列出我可以在哪里找到每个值的记录。”

一般来说，索引对于定期查询的字段来说是个好主意。定义索引的唯一缺点是它们使用额外的存储空间，因此除非您的空间非常紧张，否则您应该尝试使用它们。如果它们不适用，MySQL 无论如何都会忽略它们。

Answer 3

我不同意索引对缩短选择查询时间的重要性，但如果您可以对其他键进行索引（并使用这些索引形成您的查询），则可能不需要对时间戳进行索引。

例如，如果您有一个包含timestamp、category 和userId 的表，则最好在userId 上创建索引。在具有许多不同用户的表中，这将大大减少用于搜索时间戳的剩余集合。

...如果我没记错的话，这样做的好处是避免在每次插入时创建时间戳索引的开销——在具有高插入率和高度唯一时间戳的表中，这可能很重要考虑。

我正在努力解决基于时间戳和其他键的索引的相同问题。我还有测试要做，所以我可以证明我在这里所说的。我会根据我的结果尝试回发。

一个更好解释的场景：

1. 时间戳 99% 唯一
2. userId 80% 唯一

3. 类别 25% 独特

   • 时间戳索引将快速将查询结果减少到表大小的 1%
   • 对 userId 进行索引会迅速将查询结果减少到表大小的 20%
   • 对类别进行索引会迅速将查询结果减少到表大小的 75%
   • 在时间戳上插入索引会产生高开销**
   • 尽管我们知道我们的插入将尊重时间戳递增的事实，但我没有看到任何关于基于递增键的 MySQL 优化的讨论。
   • 在 userId 上插入索引会产生相当高的开销。
   • 在类别上插入索引将具有相当低的开销。

** 抱歉，我不知道计算出的开销或索引插入。

Answer 4

如果您的查询主要使用此时间戳，您可以测试此设计（以时间戳作为第一部分扩大主键）：

CREATE TABLE perf (
  , ts INT NOT NULL
  , oldPK 
  , ... other columns 
, PRIMARY KEY(ts, oldPK)
, UNIQUE (oldPK)
) ENGINE=InnoDB ;

这将确保您发布的查询将使用集群（主）键。

缺点是您的插入会有点慢。此外，如果表上有其他索引，它们将使用更多空间（因为它们将包括 4 字节宽的主键）。

这种聚集索引的最大优点是具有大范围扫描的查询，例如必须读取表的大部分或整个表的查询将按所需顺序（BY timestamp）按顺序查找相关行，如果您想按天、周、月或年分组，这也很有用。

通过保留UNIQUE 约束，旧的PK 仍可用于识别行。

---

您可能还想看看TokuDB，这是一个允许multiple clustered indices 的MySQL（和开源）变体。