为什么 MySQL 会选择错误的索引？答案

【问题标题】：Why does MySQL decide on wrong index?为什么 MySQL 会选择错误的索引？
【发布时间】：2013-01-03 01:28:16
【问题描述】：

我在 MySQL 中有一个如下所示的分区表：

CREATE TABLE `table1` (
   `id` bigint(19) NOT NULL AUTO_INCREMENT,
   `field1` varchar(255) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL,
   `field2_id` int(11) NOT NULL,
   `created_at` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
   PRIMARY KEY (`id`,`created_at`),
   KEY `index1` (`field2_id`,`id`)
) ENGINE=InnoDB AUTO_INCREMENT=603221206 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
/*!50100 PARTITION BY RANGE (to_days(created_at))
(PARTITION p_0 VALUES LESS THAN (730485) ENGINE = InnoDB,
  ..... lots more partitions .....
 PARTITION p_20130117 VALUES LESS THAN (735250) ENGINE = InnoDB) */;

这是对表的典型 SELECT 查询：

 SELECT field1 from TABLE1 where field2_id = 12345 and id > 13314313;

解释一下，MySQL 有时决定使用 PRIMARY 而不是 index1。当您进行第一次解释时，这似乎非常一致。然而，经过几次反复解释，MySQL 最终还是决定使用索引。问题是，这个表有数百万行，并且插入和选择以每秒几次的顺序命中它。选择错误的索引导致这些 SELECT 查询最多需要 40 秒，而不是亚秒级。无法真正安排停机时间，因此我无法在表上运行优化（由于大小，它可能需要很长时间），并且不确定在这种情况下它是否会有所帮助。

我通过强制索引解决了这个问题，所以它看起来像这样：

 SELECT field1 from TABLE1 FORCE INDEX (index1) WHERE field2_id = 12345 and id > 13314313;

我们在 MySQL 5.1.63 上运行它，目前我们无法摆脱它。

我的问题是，为什么 MySQL 选择了错误的索引？除了在所有查询上强制索引之外，还有什么可以解决的吗？分区是否混淆了 InnoDB 引擎？我用 MySQL 做了很多工作，以前从未见过这种行为。查询尽可能简单，索引也是完美匹配。我们有很多查询都假设 DB 层会做正确的事情，我不想通过所有查询来强制使用正确的索引。

更新 1：

这是典型的解释，没有 FORCE INDEX 子句。放入后，可能的键列仅显示强制索引。

 id select_type   table     type    possible_keys    key     key_len  ref   rows
  1 SIMPLE        table1    range   PRIMARY,index1   index1  12       NULL  207

【问题讨论】：

张贴EXPLAIN 的声明。
可能是因为id 是index1 的次要成员，但却是PK 的第一个成员。如果所讨论的字段是键的主要成员，则> 13314313 检查会更容易，该键将按连续顺序存储。使用index1 设置，它是次要成员，因此mysql 可能认为必须检查index 的每个“块”以进行> 查找可能需要更多的工作，即使它已经不得不这样做了field2_id 业务反正。
在自动递增的 id 和时间戳上形成 PK 是否有好处？尤其是在 id 总是递增的 InnoDB 环境中，无论时间戳是否递增！
@Strawberry 非常有效的点有点多余。
顺便说一句，任何索引都隐式包含最后的主键，即您的index1 声明是多余的

标签： mysql indexing database-performance

【解决方案1】：

我不确定引擎为什么会选择不正确的索引。我认为具有 EQUALITY 测试的索引将取代具有 >、

WHERE field2_id = 12345 and id > 13314313

改为

WHERE field2_id = 12345 and id + 0 > 13314313

【讨论】：

【解决方案2】：

我不是 100% 确定，但我认为这听起来很合乎逻辑：

您对表进行分区BY RANGE (to_days(created_at))。 created_at 字段是 primary_key 的一部分。您的选择查询正在使用主键的另一部分。这样，服务器优化引擎认为这将是最快的索引 - 使用分区和 id-primary-part。

我建议（不知道导致您选择的真正原因）将您的分区范围更改为 id 并更改您的 index1-key 的顺序。

有关分区的更多信息have a look

【讨论】：