优化MySQL SELECT语句中TIMESTAMP字段的WHERE条件

我正在为一个跟踪使用时间的分析系统设计一个模式，并且需要查看特定日期范围内的总使用时间。

举一个简单的例子，这种查询类型将经常运行：

select sum(diff_ms) from writetest_table where time_on > ("2015-07-13 15:11:56");

在人口众多的表上，此查询通常需要7秒钟左右。它有约3500万行，运行在Amazon RDS（db.m3.xlarge）上的MySQL上的MyISAM。

摆脱WHERE子句可以使查询仅花费4秒，而添加第二个子句（time_off> XXX）则需要增加1.5秒，从而使查询时间达到8.5秒。

因为我知道通常会完成这些类型的查询，所以我想优化一些东西，使其更快，最好在5秒以下。

我从在time_on上添加索引开始，尽管它大大加快了WHERE“ =”查询，但对“>”查询没有影响。有没有一种方法可以创建可以加快WHERE“>”或“ <”查询的索引？

或者，如果还有其他建议可以查询此类查询的性能，请告诉我。

注意：我使用“ diff_ms”字段作为非规范化步骤（它等于time_off-time_on），这将聚合的性能提高了大约30％-40％。

我正在使用以下命令创建索引：

ALTER TABLE writetest_table ADD INDEX time_on (time_on) USING BTREE;

在原始查询上运行“ explain”（使用“ time_on>”）时，time_on是“ possible_key”，而select_type是“ SIMPLE”。“额外”列显示“在何处使用”，“类型”为“全部”。添加索引后，该表显示“ time_on”是“ MUL”键类型，由于同一时间可以出现两次，因此这似乎是正确的。

这是表模式：

CREATE TABLE `writetest_table` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `sessionID` int(11) DEFAULT NULL,
  `time_on` timestamp NULL DEFAULT NULL,
  `time_off` timestamp NULL DEFAULT NULL,
  `diff_ms` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `time_on` (`time_on`)
) ENGINE=MyISAM AUTO_INCREMENT=50410902 DEFAULT CHARSET=latin1;

更新：我基于ypercube的响应创建了以下索引，但这将第一次查询的查询时间增加到大约17秒！

ALTER TABLE writetest_table  ADD INDEX time_on__diff_ms__ix (time_on, diff_ms) ;

更新2：解释输出

mysql> explain select sum(diff_ms) from writetest_table where time_on > '2015-07-13 15:11:56';
+----+-------------+---------------------+-------+----------------------+----------------------+---------+------+----------+--------------------------+
| id | select_type | table               | type  | possible_keys        | key                  | key_len | ref  | rows     | Extra                    |
+----+-------------+---------------------+-------+----------------------+----------------------+---------+------+----------+--------------------------+
|  1 | SIMPLE      | writetest_table_old | index | time_on__diff_ms__ix | time_on__diff_ms__ix | 10      | NULL | 35831102 | Using where; Using index |
+----+-------------+---------------------+-------+----------------------+----------------------+---------+------+----------+--------------------------+
1 row in set (0.00 sec)

更新3：请求的查询结果

mysql> SELECT time_on FROM writetest_table ORDER BY time_on LIMIT 1;
+---------------------+
| time_on             |
+---------------------+
| 2015-07-13 15:11:56 |
+---------------------+
1 row in set (0.01 sec)

我想我已经开始理解。

当我要求你跑步时

SELECT time_on FROM writetest_table ORDER BY time_on LIMIT 1;

你说的就是2015-07-13 15:11:56你的WHERE条款

当您查询时

select sum(diff_ms) from writetest_table;

它执行了3580万行的全表扫描。

当您查询时

select sum(diff_ms) from writetest_table where time_on > ("2015-07-13 15:11:56");

它执行了3580万行的完整索引扫描。

没有WHERE子句的查询更快是完全有意义的。为什么呢

表扫描将在一次线性扫描中读取3580万行。

使用WHERE进行的查询中的EXPLAIN也显示3580万行。索引扫描的行为会有所不同。尽管BTREE保持键的顺序，但进行范围扫描却很恐怖。在您的特定情况下，您正在执行最坏的范围扫描，该扫描具有与表中的行相同数量的BTREE条目。MySQL必须遍历BTREE页面（至少跨叶节点）以读取值。此外，time_on必须按照索引指示的顺序对列进行比较。因此，也必须遍历非叶BTREE节点。

请查看我在BTREE上的帖子

• Aug 06, 2013：在MySQL中，如果列X具有唯一值，那么UNIQUE索引和B-Tree索引之间有什么区别
• Jun 28, 2012：BTREE在MySQL中的好处

如果查询是今天的午夜

select sum(diff_ms) from writetest_table where time_on >= ("2015-07-14 00:00:00");

甚至今天中午

select sum(diff_ms) from writetest_table where time_on >= ("2015-07-14 12:00:00");

它应该花费更少的时间。

故事的寓意：不要使用WHERE子句来进行与目标表中的行数相等的有序范围扫描。

对于特定查询：

select sum(diff_ms) 
from writetest_table 
where time_on > '2015-07-13 15:11:56' ;     -- use single quotes, not double

索引(time_on, diff_ms)将是最好的选择。因此，如果查询经常运行，或者查询的效率对您的应用程序至关重要，请添加以下索引：

ALTER TABLE writetest_table 
  ADD INDEX time_on__diff_ms__ix      -- pick a name for the index
    (time_on, diff_ms) ;

_{（与问题无关）
确实，将表的引擎更改为InnoDB。是2015年，而MyISAM的葬礼是几年前的事。
（/ rant）}