當Mysql在where子句中不存在時，為什么決定對Order By子句中指定的列使用索引？

Question

為什么Mysql決定對Order By子句中指定的列使用索引，盡管where子句中不存在該列？ 當在查詢中一起使用Order By + Limit子句時，會發生這種情況。

查詢示例：

select col1, col2,col3 from table_name where col1 = 'x' and col3='y' order by colY limit 3;

table_name有9M條記錄

在沒有限制子句的情況下，mysql使用col1列上的索引，該索引更快。

Answer 1

更好

select  col1, col2,col3
    from  table_name
    where  col1 = 'x'
      and  col3 = 'y'
    order by  col4
    limit  3;

最佳索引是以下兩個之一：

INDEX(col1, col3, col4)
INDEX(col3, col1, col4)

在這兩種情況下，由於LIMIT ，Optimizer都可以完全解析WHERE並執行ORDER BY甚至在3行之后停止。

最好。 將col2添加到任何一個的末尾將獲得更好的性能。 這使其成為“覆蓋”索引，因此所有工作都可以在索引的BTree中完成，而無需觸及數據的BTree。

回到您的問題

如果沒有這些索引之一，則優化器陷入困境，並且經常會從兩個可能的選擇中選擇錯誤。 假設您只有

INDEX(col1), INDEX(col4)

計划A着重於過濾：使用col1 ，但是必須在剝離3之前對所有匹配的行進行排序。但是，它可能會得到一百萬行並必須對其進行排序。

計划B避免排序：按col4順序掃描索引。 如果真的很幸運，則前3行將匹配WHERE子句。 如果確實不走運，它將掃描整個表，而不會找到3個可接受的行。 但是它們會被排序！

“統計”是微不足道的，不能現實地在兩個選擇之間做出選擇。

任何一個計划都可能真的很慢。

在兩個表上使用WHERE子句過濾的JOINs也會發生類似的問題。