为什么MySQL查询优化器会选择聚集主索引上的二级索引？

Question

为什么Mysql优化器在执行'select*from lookup'而没有order by子句时选择二级索引.

它只是一个侥幸,或者这是一个幕后优化,假设你添加了一个二级索引,它比主键更重要.

我希望通过主键对结果进行排序,因为扫描所有叶节点可以提供回答此查询所需的所有数据.

要重现我创建一个简单的键/值对表(注意不是auto_increment)

create table lookup (
id int not null,
primary key (id),
name varchar(25),
unique k_name (name)
) engine=innodb;

以随机非字母顺序插入一些数据

insert into lookup values(1, "Zebra"),(2, "Aardvark"),(3, "Fish"),(4,"Dog"),(5,"Cat"),(6,"Mouse");

查询数据(这是我希望以主键的顺序返回数据的地方)

mysql> select * from lookup;
+----+----------+
| id | name     |
+----+----------+
|  2 | Aardvark |
|  5 | Cat      |
|  4 | Dog      |
|  3 | Fish     |
|  6 | Mouse    |
|  1 | Zebra    |
+----+----------+
6 rows in set (0.00 sec)

但事实并非如此 - 似乎已经完成了对k_name叶节点的扫描.这里显示

mysql> explain select * from lookup;
+----+-------------+--------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table  | type  | possible_keys | key    | key_len | ref  | rows | Extra       |
+----+-------------+--------+-------+---------------+--------+---------+------+------+-------------+
|  1 | SIMPLE      | lookup | index | NULL          | k_name | 28      | NULL |    6 | Using index |
+----+-------------+--------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

对我来说,这说Mysql使用k_name作为覆盖索引来返回数据.如果我删除k_name索引,则以主键顺序返回数据.如果我添加另一个未索引的列,则以主键顺序返回数据.

有关我的设置的一些基本信息.

mysql> show table status like 'lookup'\G
*************************** 1. row ***************************
           Name: lookup
         Engine: InnoDB
        Version: 10
     Row_format: Compact
           Rows: 6
 Avg_row_length: 2730
    Data_length: 16384
Max_data_length: 0
   Index_length: 16384
      Data_free: 0
 Auto_increment: NULL
    Create_time: 2011-11-15 10:42:35
    Update_time: NULL
     Check_time: NULL
      Collation: latin1_swedish_ci
       Checksum: NULL
 Create_options:
        Comment:
1 row in set (0.00 sec)

 mysql> select version();
 +------------+
 | version()  |
 +------------+
 | 5.5.15-log |
 +------------+
 1 row in set (0.00 sec)

Answer 1

实际上，聚集索引（又名gen_clust_index）的填充顺序除了 rowid 顺序外没有任何规律或原因。实际上不可能按照 id 顺序对 rowids 进行排序。

在 InnoDB 中，非聚集索引（也称为二级索引）中的记录包含不在二级索引中的行的主键列。InnoDB 使用此主键值来搜索聚集索引中的行。

二级索引控制顺序。但是，每个二级索引条目都有一个指向正确行的主键条目。另外，请考虑您提到的 k_name 覆盖索引场景。

现在，让我们换个话题来讨论 PRIMARY KEY 和 k_name：

问题：谁的原始查询请求的列更多，是主键还是 k_name ？

答案：k_name，因为它同时包含名称和 ID（ID 是内部的，因为它是主键）。覆盖索引 k_name 比主键更好地满足查询。

现在，如果查询是SELECT * FROM ORDER BY id，您的 EXPLAIN PLAN 应该如下所示：

mysql> explain select * from lookup order by id;
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------+
| id | select_type | table  | type  | possible_keys | key     | key_len | ref  | rows | Extra |
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------+
|  1 | SIMPLE      | lookup | index | NULL          | PRIMARY | 4       | NULL |    6 |       |
+----+-------------+--------+-------+---------------+---------+---------+------+------+-------+

1 row in set (0.00 sec)

在不指定顺序的情况下，MySQL 查询优化器会选择最能满足您的查询的索引。当然，k_name 具有不公平的优势，因为

• 表中的每一列都单独索引
• 表中的每一列都是一个候选键
• k_name 不是辅助索引，因为它是一个候选键，就像主键一样。
• 用户定义的聚集索引一旦建立就不能更改行顺序

您根本无法操纵行的顺序。这是证明：

mysql> alter table lookup order by name;
Query OK, 6 rows affected, 1 warning (0.23 sec)
Records: 6  Duplicates: 0  Warnings: 1

mysql> show warnings;
+---------+------+-----------------------------------------------------------------------------------+
| Level   | Code | Message                                                                           |
+---------+------+-----------------------------------------------------------------------------------+
| Warning | 1105 | ORDER BY ignored as there is a user-defined clustered index in the table 'lookup' |
+---------+------+-----------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> alter table lookup order by id;
Query OK, 6 rows affected, 1 warning (0.19 sec)
Records: 6  Duplicates: 0  Warnings: 1

mysql> show warnings;
+---------+------+-----------------------------------------------------------------------------------+
| Level   | Code | Message                                                                           |
+---------+------+-----------------------------------------------------------------------------------+
| Warning | 1105 | ORDER BY ignored as there is a user-defined clustered index in the table 'lookup' |
+---------+------+-----------------------------------------------------------------------------------+
1 row in set (0.00 sec)