在InnoDB表中，将主键作为复合二级索引的最后一列有什么作用？

假设我有一对一的关系(person_id, pet_id)。我有一个表在哪里pet_id是主键。

我了解InnoDB二级索引实际上是一个B树，其中的值是该行的相应主键值。

现在，假设一个人可以养成千上万只宠物，而我经常想要一个人的宠物按顺序排列pet_id。那么，如果在第二个索引记录的排序会的问题(person_id, pet_id)或只是person_id用pet_id的该person_id是无序。猜后来。

因此，如果person_id是非唯一的，记录是按(person_id, pet_id)还是JUST 物理排序的pet_id？

谢谢

否。如果您的表具有InnoDB引擎且PRIMARY KEYis为(pet_id)，则将二级索引定义为(person_id)或(person_id, pet_id)没有区别。

索引也包括该pet_id列，因此(person_id, pet_id)在两种情况下都对值进行排序。

像您这样的查询：

SELECT pet_id FROM yourtable 
WHERE person_id = 127 
ORDER BY pet_id ;

将只需要访问索引即可获取值，甚至更多，它不需要进行任何排序，因为pet_id值已经在索引中进行了排序。您可以通过查看执行计划（EXPLAIN）进行验证：

首先，我们尝试使用MyISAM表：

 CREATE TABLE table pets 
 ( pet_id int not null auto_increment PRIMARY KEY, 
   person_id int not null, 
   INDEX person_ix (person_id)
 ) ENGINE = myisam ;

INSERT INTO pets (person_id) 
VALUES (1),(2),(3),(1),(2),(3),(4),(1),(8),(1),(2),(3) ;

mysql> EXPLAIN SELECT pet_id FROM pets 
               WHERE person_id = 2  
               ORDER BY pet_id asc \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: pets
         type: ref
possible_keys: person_ix
          key: person_ix
      key_len: 4
          ref: const
         rows: 3
        Extra: Using where; Using filesort
1 row in set (0.00 sec)

注意文件排序！

现在，具有复合索引的MyISAM：

 DROP TABLE IF EXISTS pets ;

 CREATE TABLE table pets 
 ( pet_id int not null auto_increment PRIMARY KEY, 
   person_id int not null, 
   INDEX person_ix (person_id, pet_id)            -- composite index
 ) ENGINE = myisam ;

INSERT INTO pets (person_id) 
VALUES (1),(2),(3),(1),(2),(3),(4),(1),(8),(1),(2),(3) ;


mysql> EXPLAIN SELECT pet_id FROM pets 
               WHERE person_id = 2  
               ORDER BY pet_id asc \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: pets
         type: ref
possible_keys: person_ix
          key: person_ix
      key_len: 4
          ref: const
         rows: 3
        Extra: Using where; Using index
1 row in set (0.00 sec)

Filesort消失了，正如预期的那样。

现在让我们使用InnoDB引擎尝试相同的操作：

 DROP TABLE IF EXISTS pets ;

 CREATE TABLE table pets 
 ( pet_id int not null auto_increment PRIMARY KEY, 
   person_id int not null, 
   INDEX person_ix (person_id)            -- simple index
 ) ENGINE = innodb ;                      -- InnoDB engine

INSERT INTO pets (person_id) 
VALUES (1),(2),(3),(1),(2),(3),(4),(1),(8),(1),(2),(3) ;

mysql> EXPLAIN SELECT pet_id FROM pets 
               WHERE person_id = 2  
               ORDER BY pet_id asc \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: pets
         type: ref
possible_keys: person_ix
          key: person_ix
      key_len: 4
          ref: const
         rows: 3
        Extra: Using where; Using index
1 row in set (0.00 sec)

也没有文件排序！即使索引没有显式包含该pet_id列，这些值仍在此处并进行排序。您可以检查是否使用定义了索引(person_id, pet_id)，该索引EXPLAIN是否相同。

让我们使用InnoDB和复合索引实际执行此操作：

 DROP TABLE IF EXISTS pets ;

 CREATE TABLE table pets 
 ( pet_id int not null auto_increment PRIMARY KEY, 
   person_id int not null, 
   INDEX person_ix (person_id, pet_id)    -- composite index
 ) ENGINE = innodb ;                      -- InnoDB engine

INSERT INTO pets (person_id) 
VALUES (1),(2),(3),(1),(2),(3),(4),(1),(8),(1),(2),(3) ;

mysql> EXPLAIN SELECT pet_id FROM pets 
               WHERE person_id = 2  
               ORDER BY pet_id asc \G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: pets
         type: ref
possible_keys: person_ix
          key: person_ix
      key_len: 4
          ref: const
         rows: 3
        Extra: Using where; Using index
1 row in set (0.00 sec)

与前一个案例的计划相同。

为了100％的确定，我还运行了后两种情况（InnoDB引擎，具有单索引和复合索引），以启用file_per_table设置并在表中添加数千行：

DROP TABLE IF EXISTS ... ;
CREATE TABLE ... ;

mysql> INSERT INTO pets (person_id) 
       VALUES (1),(2),(3),(1),(2),(3),(4),(1),(8),(1),(2),(3) ;
Query OK, 12 rows affected (0.00 sec)
Records: 12  Duplicates: 0  Warnings: 0

mysql> INSERT INTO pets (person_id) 
       VALUES (1),(2),(3),(1),(2),(3),(4),(1),(8),(1),(2),(3),(127) ;
Query OK, 13 rows affected (0.00 sec)
Records: 13  Duplicates: 0  Warnings: 0

mysql> INSERT INTO pets (person_id) 
       VALUES (1),(2),(3),(1),(2),(3),(4),(1),(8),(1),(2),(3),(127) ;
Query OK, 13 rows affected (0.00 sec)
Records: 13  Duplicates: 0  Warnings: 0

mysql> INSERT INTO pets (person_id) 
       SELECT a.person_id+b.person_id-1 
       FROM pets a CROSS JOIN pets b CROSS JOIN pets c ;
Query OK, 54872 rows affected (0.47 sec)
Records: 54872  Duplicates: 0  Warnings: 0

在这两种情况下，检查实际文件大小都会产生相同的结果：

ypercube@apollo:~$ sudo ls -la /var/lib/mysql/x/ | grep pets
-rw-rw----  1 mysql mysql     8604 Apr 21 07:25 pets.frm
-rw-rw----  1 mysql mysql 11534336 Apr 21 07:25 pets.ibd

根据有关簇索引和二级索引的MySQL文档

二级索引如何与聚簇索引相关

除聚集索引以外的所有索引都称为辅助索引。在InnoDB中，二级索引中的每个记录都包含该行的主键列以及为二级索引指定的列。InnoDB使用此主键值在聚集索引中搜索行。

如果主键较长，则辅助索引将使用更多空间，因此具有短主键是有利的。

因此，将PRIMARY KEY添加到二级索引绝对是多余的。您的索引条目想要(person_id, pet_id, pet_id)。通过具有2个副本的，这也将不必要地使二级索引膨胀PRIMARY KEY。

对于带有的索引(person_id)，如果要运行这样的查询

SELECT * FROM yourtable WHERE person_id = 127 ORDER BY pet_id;

在PRIMARY KEY将全面参与该查询并产生结果排序的PRIMARY KEY反正。从物理角度来看，这些行按插入顺序排序。如果pet_id为AUTO_INCREMENT，则按自动编号排序。

秘诀1：

PRIMARY KEY(x, id),
INDEX(id) -- where `id` is `AUTO_INCREMENT`

是完全有效的。当许多查询需要查找多行时，它具有更高效率的性能优势WHERE x = 123。也就是说，它比“显而易见的”效率更高

PRIMARY KEY(id),
INDEX(x, id)

关于AUTO_INCREMENT（对于InnoDB）唯一的规则是id必须是某个索引的第一列。请注意，该规则未对“ 或” 或“仅列”进行说明。PRIMARYUNIQUE

提示对于通常x与其他内容一起获取的大型表很有用。

提示2：假设您有

SELECT name FROM tbl WHERE person_id = 12 AND pet_id = 34;

这是一个“覆盖”索引：

INDEX(person_id, pet_id, name)

也就是说，整个查询可以在索引的BTree中完成。EXPLAIN会说“正在使用索引”。