相信沒有人會故意創建重復的冗余的索引，很多重復和冗余的索引都是在不經意間創建的，今天松哥來和大家捋一捋這個問題。

因為我們日常在使用 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。

(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》