大型审计表上的mysql索引日期与日期时间答案

【问题标题】：mysql indexing date vs datetime on large audit table大型审计表上的mysql索引日期与日期时间
【发布时间】：2016-01-29 21:57:46
【问题描述】：

我有一个审计表，目前在 innodb 上运行大约 2500 万行，并且每月增长大约 100 万行。我目前在 datetime 列上有一个索引。出于性能原因，如果用户搜索它会限制在当天。如果我将日期时间分成两个单独的字段并在日期字段上有一个索引，索引性能会更好。我怀疑这也会创建一个较小的索引，因为您没有索引日期时间字段的每一秒。我也可以从这个表的分区中受益。

附言。目前正在运行 percona 5.5。

【问题讨论】：

标签： mysql sql percona

【解决方案1】：

这取决于查询的措辞方式。如果查询表述为：

where date(datetimecol) = curdate()

那么索引将不会被使用。如果查询表述为：

添加带有索引的日期列将提高性能：

where datecol = curdate()

如果查询表述为：

where datetimecol >= curdate () and
      datetimecol < date_add(curdate(), interval 1 day)

那么索引将（可能）被使用。

【讨论】：

我不使用你在第一个例子中展示的函数。我更多地考虑在 DATE 字段与 DATETIME 字段上的 6 个月时间范围内执行 WHERE 的性能。可能 B-Tree 索引已经针对这种情况进行了优化，因此速度上不会有真正的差异。
@tsmgeek 。 . .我不确定你关心的是什么。如果您从 6 个月的时间范围内检索数据，那么获取行的时间可能会主导查询。
我们还设置了一个限制，这样用户就不会在单个页面上撤回超过 500 次审核，但是对于大型数据集，初始搜索时间可能需要一段时间。这更多是关于索引优化，索引可能在 DATETIME 列上过大，其中几乎每一行都是唯一的，但如果我要使用 DATE，那么它会有更好的基数。
@tsmgeek 。 . .您应该问另一个问题并显示整个查询。例如，如果您有一个order by，那么这可能是导致性能不佳的原因。