mysql - 为什么 MySQL 会选择错误的索引？

Question

我在 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

Answer 1

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

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

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

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