为什么向 MySQL 表添加重复索引会导致查询执行时间变长？

Question

也许索引不相关，但我遇到了一个奇怪的问题。

这是我的选择查询：

SELECT DISTINCT completeAddress FROM DB_M3_Medium.AvailableAddressesV3 where postNr = 1050 ORDER BY completeAddress ASC;

我的索引：

create index postNrAndAddress_idx on DB_M3_Medium.AvailableAddressesV3 (completeAddress);
create index postNr_idx on DB_M3_Medium.AvailableAddressesV3 (completeAddress);
create index completeAddress_idx on DB_M3_Medium.AvailableAddressesV3 (completeAddress);

除此之外，我还有一个自动增量 ID (idIndex) 的 PK。

在任何手动创建的索引出现之前，选择查询的执行时间为 2.4 秒。

然后我创建了索引（一个一个）：

• 第一个索引 - 选择语句执行时间 - 2.1s
• 第二个索引 - 选择 语句执行时间 - 2.8s
• 第三个索引 - 选择语句 执行时间 - 12.7 秒

刚刚发生了什么？

编辑：

谢谢你们的cmets。我的解释语句结果：

+----+-------------+----------------------+-------+-----------------------------------------------------+---------------------+---------+-----+---------+-------------+
| id | select_type |        table         | type  |                    possible_keys                    |         key         | key_len | ref |  rows   |    Extra    |
+----+-------------+----------------------+-------+-----------------------------------------------------+---------------------+---------+-----+---------+-------------+
|  1 | SIMPLE      | AvailableAddressesV3 | index | postNrAndAddress_idx,postNr_idx,completeAddress_idx | completeAddress_idx |     363 |     | 3526406 | Using where |
+----+-------------+----------------------+-------+-----------------------------------------------------+---------------------+---------+-----+---------+-------------+

表结构：

+------------------+--------------+------+-----+---------+----------------+
|      Field       |     Type     | Null | Key | Default |     Extra      |
+------------------+--------------+------+-----+---------+----------------+
| vej_Navn         | varchar(70)  | YES  |     |         |                |
| husNr            | varchar(20)  | YES  |     |         |                |
| husbogstav       | varchar(50)  | YES  |     |         |                |
| etage            | varchar(30)  | YES  |     |         |                |
| side_DoerNr      | varchar(20)  | YES  |     |         |                |
| stedNavn         | varchar(50)  | YES  |     |         |                |
| postNr           | varchar(15)  | YES  | MUL |         |                |
| postDistrikt     | varchar(50)  | YES  |     |         |                |
| lev_Adresse_UUID | varchar(50)  | YES  |     |         |                |
| fiberstatus      | varchar(15)  | YES  |     |         |                |
| kommune_nr       | varchar(35)  | YES  |     |         |                |
| vej_Kode         | varchar(35)  | YES  |     |         |                |
| completeAddress  | varchar(120) | YES  | MUL |         |                |
| randomSalt       | varchar(5)   | YES  |     |         |                |
| id               | int(11)      | NO   | PRI |         | auto_increment |
+------------------+--------------+------+-----+---------+----------------+

创建表查询：

  CREATE TABLE `AvailableAddressesV3` (
  `vej_Navn` varchar(70) COLLATE utf8_unicode_ci DEFAULT NULL,
  `husNr` varchar(20) COLLATE utf8_unicode_ci DEFAULT NULL,
  `husbogstav` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  `etage` varchar(30) COLLATE utf8_unicode_ci DEFAULT NULL,
  `side_DoerNr` varchar(20) COLLATE utf8_unicode_ci DEFAULT NULL,
  `stedNavn` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  `postNr` varchar(15) CHARACTER SET utf8 DEFAULT NULL,
  `postDistrikt` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  `lev_Adresse_UUID` varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
  `fiberstatus` varchar(15) COLLATE utf8_unicode_ci DEFAULT NULL,
  `kommune_nr` varchar(35) COLLATE utf8_unicode_ci DEFAULT NULL,
  `vej_Kode` varchar(35) COLLATE utf8_unicode_ci DEFAULT NULL,
  `completeAddress` varchar(120) COLLATE utf8_unicode_ci DEFAULT NULL,
  `randomSalt` varchar(5) COLLATE utf8_unicode_ci DEFAULT NULL,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  UNIQUE KEY `idIndex` (`id`),
  KEY `postNrAndAddress_idx` (`postNr`,`completeAddress`),
  KEY `postNr_idx` (`postNr`),
  KEY `completeAddress_idx` (`completeAddress`)
) ENGINE=InnoDB AUTO_INCREMENT=3552718 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Answer 1

根据您的 EXPLAIN 输出，查询使用completeAddress_idx，可能是因为排序/不同，但我猜postNr = 1050 的行很少（在哥本哈根，对吗？）所以它使用postNr_idx 或postNrAndAddress_idx 应该更有效（几百行的排序/区分应该几乎是即时的）。某些事情使查询执行计划者错过了最佳查询。

我自己从未尝试过，但您可以尝试更新表统计信息的 ANALYZE TABLE 语句，例如键基数，这可能会改变优化器的工作方式。

要么这样，要么我错过了一些简单的东西 - 这似乎很可能:)

编辑

在调试时，强制 MySQL 使用特定索引会很有用。试试FORCE/USE INDEX hint。

Answer 2

我从没想过这会成为问题，或者至少我会收到WorkBench 或JDBC 的错误通知或至少是警告。

我的选择查询应该如下所示：

SELECT DISTINCT completeAddress FROM DB_M3_Medium.AvailableAddressesV3 where postNr = '4000' ORDER BY completeAddress ASC;

区别在于postNr 的数据类型。在我没有将它包裹在 ' 之前。

这极大地改善了选择，然后当我删除 ORDER BY 时，执行时间下降到 0.07 秒。

所以基本上发生了什么，SELECT 查询没有使用任何索引，因为没有一个索引是合适的。当我执行EXPLAIN 时，我的 Key 列收到 NULL。我试图FORCE 它，但它没有任何区别。

然后我发现了这个：Why isn't MySQL using any of these possible keys?

他在第二个答案中提到的地方。