當在SELECT中存在多個字段時，mysql ORDER BY沒有使用索引

我試圖簡化一個查詢來找出爲什麼它在生產服務器上如此之慢。這個想法是抓住X最近的條目分頁。問題是，MySQL的優化器似乎想要使用filesort而不是主鍵（ID）。剝離掉所有多餘的東西，下面的作品需要，使用索引（主）：當在SELECT中存在多個字段時，mysql ORDER BY沒有使用索引

EXPLAIN SELECT ID FROM table ORDER BY ID DESC

然而，這些變化訴諸文件排序：

EXPLAIN SELECT ID, field2 FROM table ORDER BY ID DESC 
EXPLAIN SELECT * FROM table ORDER BY ID DESC

我需要返回的幾個字段，所以還是不行...我能找到解決這個問題的簡單查詢有：

EXPLAIN SELECT * FROM table FORCE INDEX (Primary) ORDER BY ID DESC

，但我還沒有想出如何工作是到大的查詢與表連接。我錯過了很簡單的事情嗎？

來源

2012-02-21 overflowing

強迫使用索引加快查詢？如果您需要閱讀表格的所有記錄（因爲它看起來像你），也許使用索引是沒有意義的。「這個想法是抓住X最近的分頁條目」。那麼在某處應該有LIMIT子句。否則數據庫認爲你想要他們全部。 – Thilo 2012-02-21 04:05:28

對不起，我沒有提到LIMIT子句，因爲這是我爲上述示例剝離的一部分。使用LIMIT似乎沒有任何作用 - 它仍然每次都使用filesort。我沒有讓它運行生產服務器上的FORCE INDEX速度測試;那只是通過EXPLAIN測試的。 – overflowing 2012-02-21 04:15:34

嘗試此查詢

select * from table order by id desc limit (pageNO-1) * noEntries , noEntries

如第1頁和10項每

頁

select * from table order by id desc limit 0, 10

例如2頁和10項每

頁

select * from table order by id desc limit 10, 10

來源

2012-02-21 04:20:40

查看我對以上Thilo的回覆。在LIMIT子句中添加仍然使用filesort。這首先讓我感到困惑的部分，導致我剝去了所有的東西，直到我能夠更好地瞭解發生了什麼。 – overflowing 2012-02-21 04:25:51

是唯一的ID字段 – 2012-02-21 05:26:19

是的，它是表的主鍵，因此是唯一的。 – overflowing 2012-02-21 05:58:46

問題解決了！我經過多次修改去了，也不敢保證哪一個是關鍵，但我認爲最主要的是運行OPTIMIZE TABLE，其具有以下效果清理：

Type  Usage 
Data  241.2 KiB -> 239.4 
Index  31,744 B -> 26,624 
Overhead 136 B  -> 0 
Effective 272.0 KiB 
Total  272.2 KiB -> 265.4

就這樣，我就能夠運行「解析SELECT ID，field2 FROM table ORDER BY ID DESC LIMIT 0,10」而不使用filesort，所以這是一個好的開始。從那裏開始，我開始再次構建主查詢，並遇到DISTINCT（ID）問題，導致它無法將主鍵用作索引。然而，它需要在那裏，因爲ID字段加入的表中有一個表中有每個ID的多個條目。但是，用GROUP BY ID替換DISTINCT（ID）卻有竅門。這在以前沒有用，所以我想知道它是否與優化表有關？無論如何，感謝您在嘗試性幫助時插上了它！

來源

2012-02-21 16:37:12 overflowing

這是暗示的，但我應該提到，查詢使用索引而不是文件對性能有巨大影響。之前，它會看起來無限期地掛起來，現在幾乎是瞬間的。 – overflowing 2012-02-21 18:50:41

當在SELECT中存在多個字段時，mysql ORDER BY沒有使用索引

回答

相關問題