共计 1834 个字符，预计需要花费 5 分钟才能阅读完成。
置信没有人会成心创立反复的冗余的索引，很多反复和冗余的索引都是在不经意间创立的，明天松哥来和大家捋一捋这个问题。
因为咱们日常在应用 MySQL 的过程中，基本上都是应用 InnoDB 引擎，所以接下来的探讨次要是基于 InnoDB 引擎的 B+Tree 索引来探讨，其余的哈希索引全文索引等不在探讨范畴种。
1. 与联结索引反复
在后面的文章中，松哥通过好几篇文章和大家分享了联结索引，包含它波及到的笼罩索引、前缀匹配等等，联结索引好用，然而对联结索引了解不到位的话，可能会创立出如下的反复索引：
CREATE TABLE `user2` (`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`address` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`password` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`email` varchar(16) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `user_index1` (`username`,`address`),
KEY `user_index2` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;能够看到，这里创立了两个索引：
- user_index1: 这个索引蕴含两个字段，username 在前 address 在后。
- user_index2: 这个索引蕴含一个字段 username。
在其实 MySQL 中的 like 关键字也能用索引！一文中，松哥跟大家聊了索引的最左匹配准则，即：
(username,address) 索引既能够当成联结索引来用，也能够通过最左匹配准则当成独自的 (username) 索引来用。
所以，如果再为 username 字段独自创立一个索引就没有必要了，这反而会导致增删改的时候速度变慢。
不过怎么说呢，下面这个论断实用于 99% 的场景，可能会有一些非凡状况，例如想把 (username) 和某一个特地长的字段建设一个联结索引，此时如果独自应用 username 字段进行搜寻的话，效率可能升高，此时视搜寻的重要水平，看是否须要创立一个反复的索引。
2. 主键退出联结索引中
来看看上面这个索引：
CREATE TABLE `user2` (`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`address` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`password` varchar(32) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`email` varchar(16) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `user_index` (`username`,`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; 一个名为 user_index 的索引中蕴含了两个字段 username 和 id，其中 id 是主键。
在什么是 MySQL 的“回表”？一文中，松哥和大家聊了，索引依照物理存储形式能够分为聚簇索引和非聚簇索引。
咱们日常所说的主键索引，其实就是聚簇索引（Clustered Index）; 主键索引之外，其余的都称之为非主键索引，非主键索引也被称为二级索引（Secondary Index），或者叫作辅助索引。
对于主键索引和非主键索引，应用的数据结构都是 B+Tree，惟一的区别在于叶子结点中存储的内容不同：
- 主键索引的叶子结点存储的是一行残缺的数据。
- 非主键索引的叶子结点存储的则是主键值以及索引列的值。
这是两者最大的区别。
既然主键曾经存在于叶子结点中，那当然没有在联结索引中退出主键了。
好啦，几个小小的留神点，心愿能给小伙伴们启发。
参考资料：
- 《高性能 MySQL》
