MySQL的QueryOptimizer似乎随机使用索引（或不）

Question

我刚刚发现MySQL使用InnoDB引擎的以下行为。有没有办法解释执行时间的显着差异？

首先查询：

SELECT ask FROM history_time WHERE ask> 1.5790 AND timestamp BETWEEN 1207000800290 AND  1207690900290 

执行时间：0.715sec

EXPLAIN: '1', 'SIMPLE', 'history_time', 'range', 'PRIMARY,timestamp,ask,ask_2', 'PRIMARY', '8', NULL, '3278190','Using where' 

第二个查询：

SELECT ask FROM history_time WHERE ask> 1.5790 AND timestamp > 1207000800290 

执行时间：0.002sec

EXPLAIN: '1', 'SIMPLE', 'history_time', 'range', 'PRIMARY,timestamp,ask,ask_2', 'ask', '4', NULL, '5850604', 'Using where; Using index' 

第三个查询：

SELECT ask FROM history_time WHERE ask> 1.5790 AND timestamp < 1207690900290 

执行时间：0.651sec

EXPLAIN: '1', 'SIMPLE', 'history_time', 'range', 'PRIMARY,timestamp,ask,ask_2', 'PRIMARY', '8', NULL, '3278190', 'Using where' 

EXPLAIN告诉我，只有第二个查询使用索引。我的表格包含83 Mio.行，主键是时间戳。我也有一个索引（问，时间戳）和一个询问（这是多余的，只为测试目的）。为什么MySQL只在第二个查询中使用索引？

Answer 1

你的答案是：The Range Access Method for Multiple-Part Indexes

编辑：，你也将更好地检查：mysql range index。优化器有可能决定使用全扫描然后索引会更快。

Answer 2

您的查询具体使用时间戳记作为主键，也是通过您的评论（问，时间戳）询问的索引。交换它......你希望第一个位置的粒度更小......（时间戳，问）......除非你要求一个非常具体的询问值或询问值的范围。这样想想吧。

如果你有8300万行，你所要求的东西X和Y的时间内发生了，时间戳是你的基础...为什么要考虑什么比有问题的区域小或更大。现在，添加“ask> someValue”，优化器可能会感到困惑。猜猜...有更少的值大于问题值，或者更少的值是基于提供的时间戳范围。如果你有一个索引（时间戳，问），它可以更好地利用它。在提供的范围内，只需要询问> SomeValue。

如果优化器使用了当前的Ask索引，它基本上会遍历所有大于所提供值的条目......然后在每个条目中跳转到时间戳范围内的条目。

现在，更换您的条件。如果你正在寻找一个特定的“询问”值或范围，那么你当前的指标将会非常好。它只会关注这个范围。