為什么即使使用LIMIT子句，查詢在mysql中也需要很長時間？

Question

假設我有一個包含100多列和100萬行的Order表。 它在OrderID和FK約束StoreID上有一個PK - > Store.StoreID。

1） select * from 'Order' order by OrderID desc limit 10;

以上需要幾毫秒。

2） select * from 'Order' o join 'Store' s on s.StoreID = o.StoreID order by OrderID desc limit 10;

這種方式可能需要很長時間。 我添加的內連接越多，就越慢。

3） select OrderID, column1 from 'Order' o join 'Store' s on s.StoreID = o.StoreID order by OrderID desc limit 10;

這似乎通過限制我們選擇的列來加快執行速度。

有幾點我在這里不明白，如果有更多知識的mysql（或一般的rmdb查詢執行）可以啟發我，我會非常感激。

查詢1很快，因為它只是PK的反向查找，而DB只需返回它遇到的前10行。

我不明白為什么查詢2應該永遠采用。 操作不應該一樣嗎？ 即通過PK獲取前10行， 然后與其他表連接。 由於存在FK約束，因此可以保證滿足關系。 因此DB不需要連接超過必要的行，然后修剪結果，對嗎？ 除非，FK約束允許空FK？ 在這種情況下，我猜左連接會比內連接快得多嗎？

最后，我猜測查詢3的速度更快，因為在這些不必要的連接中使用了更少的列？ 但是為什么在加入時查詢執行需要其他列？ 它不應該首先使用PK加入，然后只獲取10行的列？

謝謝！

Answer 1

我的理解是，在任何join發生后，mysql引擎都會應用limit 。

從http://dev.mysql.com/doc/refman/5.0/en/select.html開始 ， The HAVING clause is applied nearly last, just before items are sent to the client, with no optimization. (LIMIT is applied after HAVING.) The HAVING clause is applied nearly last, just before items are sent to the client, with no optimization. (LIMIT is applied after HAVING.)

編輯：您可以嘗試使用此查詢來利用PK速度。

select * from (select * from 'Order' order by OrderID desc limit 10) o join 'Store' s on s.StoreID = o.StoreID;

Answer 2

您的所有示例都要求現有表的表掃描，因此它們中的任何一個都不會比mysql可以緩存數據或結果的程度更高或更低。 您的一些查詢具有order by或join條件，這可以充分利用索引來使連接過程更有效，但是，這仍然與具有一組將觸發索引使用的標准不同。

限制不是標准 - 一旦確定結果集，就可以將其視為過濾。 一旦准備好結果集，您就可以節省客戶端上的時間，但不能在服務器上節省時間。

真的，獲得你想要的答案的唯一方法就是熟悉：EXPLAIN EXTENDED your_sql_statement

EXPLAIN的輸出將顯示mysql正在查看的行數，以及是否正在使用任何索引。