為什么這個MySQL查詢即使有索引也要花這么長時間進行排序？

Question

我不明白為什么以下查詢需要這么長時間才能排序。 在概要分析中，即使排序行有索引，它也顯示排序仍然需要很長時間。

MySQL服務器是一台專用計算機，基本上在當前的Debian穩定版本中僅運行MySQL，具有32 GB的物理RAM和一個不錯的MySQL配置。 表player （INNODB）當前具有約32,000,000個條目。 表player索引：

gameplayer ， game, id, server （唯一）

id, server serverplayer id, server （索引）

date超過date （索引）<-這是我們將按照的排序

以下查詢用於獲取有關某個游戲的某個玩家的統計數據，從而獲取有關該玩家，這些統計數據和實際游戲的信息：

set profiling = 1;

SELECT *
FROM `player` `gs`
INNER JOIN `playerstats` `gss` ON (`gss`.`player` = `gs`.`id`)
INNER JOIN `game` `g` ON (`g`.`id` = `gs`.`game`)
WHERE `gs`.`id` = :id
AND `gs`.`server` = :server
ORDER BY `gs`.`date` DESC
LIMIT 10;

show profile for query 1;

set profiling = 0;

這是表演資料的結果：

starting    0.000124
Waiting for query cache lock    0.000070
checking query cache for query  0.000090
checking permissions    0.000066
checking permissions    0.000058
checking permissions    0.000056
Opening tables  0.000074
System lock 0.000058
Waiting for query cache lock    0.000093
init    0.000071
optimizing  0.000054
statistics  0.000136
preparing   0.000073
executing   0.000044
Sorting result  0.201156 // <========================
Sending data    0.042253
end 0.000046
query end   0.000038
closing tables  0.000043
freeing items   0.000042
Waiting for query cache lock    0.000037
freeing items   0.000039
Waiting for query cache lock    0.000035
freeing items   0.000032
storing result in query cache   0.000031
logging slow query  0.000030
cleaning up 0.000031

如果我對MySQL的理解正確，那么應該對WHERE條件使用serverplayer索引，對排序使用date索引，對嗎？ 那么，當我有適當的索引可用時，為什么要花這么長時間？

還是我必須將列date添加到serverplayer索引中？

Answer 1

閱讀此鏈接以獲取詳細信息： http : //dev.mysql.com/doc/refman/5.7/en/order-by-optimization.html

在您的特定情況下，此條件不滿足並且MySql不使用索引對行進行排序：

在某些情況下，MySQL仍然無法使用索引來解析ORDER BY，盡管它仍然使用索引來查找與WHERE子句匹配的行。 這些情況包括：
....
用於獲取行的密鑰與在ORDER BY使用的密鑰不同：
SELECT * FROM t1 WHERE key2=constant ORDER BY key1;
......

但是，當創建關於列id + server + date的索引時，其中id和date是WHERE子句中用於選擇行的列，而date是索引中的最后一列，上述條件不適用，MySql可以使用此索引對行進行排序並避免文件排序。