MySQL SELECT MAX vs ORDER BY LIMIT 1 on WHERE 子句

Question

SELECT MAX vs ORDER BY LIMIT 1 个问题已经在这里回答了好几次了，但是如果我添加一个 WHERE 子句，事情就会发生巨大的变化

这是我的桌子：

Field	Type	Null	Key	Default	Extra
id	b'int'	'NO'	'PRI'	None	'auto_increment'
'open_time'	b'bigint'	'NO'	'UNI'	None	''

请注意，这两列都已编入索引。

以下是请求：

SELECT id from table
WHERE open_time > 0
ORDER BY id DESC LIMIT 1

SELECT MAX(id) from BTCUSDT1mHist
WHERE open_time > 0

EXPLAIN ANALYZE 显示以下内容： 订购：

-> Limit: 1 row(s)  (cost=0.10 rows=1) (actual time=0.038..0.038 rows=1 loops=1)
    -> Filter: (table.open_time > 0)  (cost=0.10 rows=1) (actual time=0.037..0.037 rows=1 loops=1)
        -> Index scan on table using PRIMARY (reverse)  (cost=0.10 rows=2) (actual time=0.036..0.036 rows=1 loops=1)

MAX():

-> Aggregate: max(table.id)  (cost=325890.06 rows=1081033) (actual time=1025.181..1025.181 rows=1 loops=1)
    -> Filter: (table.open_time > 0)  (cost=217786.76 rows=1081033) (actual time=0.032..866.890 rows=2180645 loops=1)
        -> Index range scan on table using open_time  (cost=217786.76 rows=1081033) (actual time=0.031..705.926 rows=2180645 loops=1)

ORDER BY 在 0.0012 秒内完成，而 MAX() 在 1.026 秒内完成

我也读过这个question，但它似乎没有涵盖我的情况

问题是：为什么 MAX() 花费的时间比 ORDER BY LIMIT 长这么多？

Answer 1

在分析中比较：

    -> Index scan on table using PRIMARY (reverse)  (cost=0.10 rows=2) (actual time=0.036..0.036 rows=1 loops=1)

对比：

    -> Index range scan on table using open_time  (cost=217786.76 rows=1081033) (actual time=0.031..705.926 rows=2180645 loops=1)

检查 2 行必须比检查 2,180,645 行快很多。

在ORDER BY id DESC LIMIT 1 的查询中，它使用主键索引。它从最后开始，因为它是相反的顺序。然后它只是向下迭代索引的叶节点（按降序排列），直到它检查也匹配open_time > 0 的第一行。然后LIMIT optimization 允许查询执行完成。根据其统计数据，它估计这将在检查 2 行后发生。

在带有MAX(id) 的查询中，它使用open_time 上的索引。但是因为它是一个范围条件open_time > 0，所以它不能假设在该范围的开始或结束处找到最大的 id。因此它必须检查open_time 索引中的每个 匹配条目，搜索id 的最大值（主键隐含地属于二级索引）。与LIMIT 的查询一样，不可能提前终止。