为什么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上做了很多工作,之前从未见过这种行为.查询尽可能简单,索引也是完美匹配.我们有很多查询假设数据库层会做正确的事情,我不想通过所有这些查询强制使用正确的索引.

更新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主部分。

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

有关分区的更多信息请查看