我有一个大约500000行的表，我正在测试它的两个复合索引。第一个索引按列的顺序放在最后，第二个索引则按相反的顺序。
我不明白的是，为什么第二个索引提供了更好的性能，与第一个查询的889行相比，第二个索引估计要扫描30行，因为我觉得第二个索引不能正确使用，因为order by列不是最后一个。有人能解释为什么会这样吗？如果两者都存在，mysql更喜欢第一个索引。
请注意，第二个解释将可能的\u键列为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会提供如此相反的信息。