MySQL復合索引列的順序和性能

Question

我有一個約有500,000行的表，並且正在為此測試兩個復合索引。 第一個索引將ORDER BY列放在最后，第二個索引則相反。

我不明白的是，為什么第二個索引似乎可以通過估計要掃描的30行而不是第一個查詢的889行提供更好的性能，因為我印象中第二個索引不能正確地用作ORDER BY列不是最后的。 誰能解釋為什么會這樣？ 如果兩個索引都存在，則MySQL首選第一個索引。

請注意，第二個EXPLAIN列出了可能的鍵為NULL，但仍列出了選定的鍵。

1）第一個索引

ALTER TABLE user ADD INDEX test1_idx (city_id, quality);

（基數12942）

EXPLAIN SELECT * FROM user u WHERE u.city_id = 3205 ORDER BY u.quality DESC LIMIT 30;
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+-------------+
| id | select_type | table | type   | possible_keys | key       | key_len | ref            | rows | Extra       |
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+-------------+
|  1 | SIMPLE      | u     | ref    | test1_idx     | test1_idx | 3       | const          |  889 | Using where | 
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+-------------+

2）第二個索引（反向相同字段）

ALTER TABLE user ADD INDEX test2_idx (quality, city_id);

（基數7549）

EXPLAIN SELECT * FROM user u WHERE u.city_id = 3205 ORDER BY u.quality DESC LIMIT 30;
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+-------------+
| id | select_type | table | type   | possible_keys | key       | key_len | ref            | rows | Extra       |
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+-------------+
|  1 | SIMPLE      | u     | index  | NULL          | test2_idx | 5       | NULL           |  30  | Using where | 
+----+-------------+-------+--------+---------------+-----------+---------+----------------+------+-------------+

更新：

正如預期的那樣，第二個查詢在現實生活中的效果不佳，而第一個查詢則表現良好。 我仍然對為什么MySQL EXPLAIN提供這種相反的信息感到好奇。

Answer 1

我猜您的數據類型city_id：MEDIUMINT 3字節質量：SMALLINT 2字節

據我所知

SELECT * FROM user u WHERE u.city_id = 3205 ORDER BY u.quality DESC LIMIT 30;

第二個索引（質量，city_id）無法完全使用。 因為Order by是范圍掃描，所以只能對索引的最后一部分執行。

第一個索引看起來很完美。 我猜有一段時間Mysql不太聰明。 也許目標的city_id的數量可能會影響mysql決定將使用哪個索引。

您可以嘗試關鍵詞

FORCE INDEX(test1_idx)

Answer 2

EXPLAIN中的行只是對MySQL認為必須檢查才能產生結果的行數的估計。

我記得曾讀過Percona的Peter Zaitsev的一篇文章，說這個數字可能非常不准確。 因此，您不能簡單地根據此數字比較查詢效率。

我同意您的看法，在正常情況下，第一個索引會產生更好的結果。

您應該已經注意到，第一個EXPLAIN中的type列是ref而第二個索引是index。 ref通常比索引掃描更好。 如前所述，如果兩個鍵都存在，則MySQL首選第一個。