直逼查詢給出不同的執行時間

SELECT SQL_NO_CACHE DISTINCT(type) FROM actions LIMIT 0, 30;

和

SELECT SQL_NO_CACHE type FROM actions GROUP BY type LIMIT 0, 30;

如果我不使用LIMIT子句時，執行時間是相等的。另一方面，就我而言，第一個查詢需要將近0.8秒，而第二個需要0.12秒。

使用EXPLAIN，似乎唯一的區別是第一個查詢使用臨時表，而第二個查詢不使用臨時表。

在這一點上，我很驚訝兩個查詢的不同行爲......你能提供一些關於這個問題的啓示嗎？

我目前使用MYSQL 5.5.37-35.1的Percona服務器（GPL），版本35.1，修訂666

2014-07-02 marcosh

我推測，第二查詢管理使用利用上式指數爲GROUP BY。 – Kickstart

因爲'不同'意味着需要做額外的工作，忽略重複的條目，這就是爲什麼需要更多的時間。 –

@Kickstart根據mysql文檔，這兩個查詢都使用類型 – marcosh

看來，LIMIT優化時纔可以被正確使用GROUP BY應用時，有一個ORDER BY條款。正如Gordon Linoff在較早的（刪除的）答案中所建議的那樣，GROUP BY查詢有一個隱含的ORDER BY。因此，GROUP BY查詢使用LIMIT優化。

儘管DISTINCT查詢基本上使用GROUP BY來解決它，但隱含的ORDER BY不存在。添加一個明確的ORDER BY條款的DISTINCT查詢產生相同的執行計劃和相同的性能GROUP BY查詢：

SELECT SQL_NO_CACHE DISTINCT(type) FROM actions ORDER BY type LIMIT 0, 30;

和

SELECT SQL_NO_CACHE type FROM actions GROUP BY type LIMIT 0, 30;

2014-07-02 14:38:59

我絕對同意。（我想知道爲什麼答案被刪除:)）但我想知道爲什麼DISTINCT不會隱式地使用ORDER BY，當有一個索引會使它快。而且，我對這個問題中的問題進行了類似的查詢，最終的結果是以相同的順序 - 你認爲這是因爲某種原因而預期的嗎？謝謝 – idrarig

@idrarig，我猜這是隱式或顯式的'ORDER BY'觸發LIMIT優化，無論發生了什麼。需要改進的空間可以確定。 –

回答