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

我不是百分百肯定，但我认为这听起来很合乎逻辑：

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

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

有关分区have a look

的更多信息

Answer 2

我不确定为什么引擎会选择不正确的索引。我认为具有EQUALITY测试的索引将取代具有＆gt;，＆lt;的索引。或范围。但是，另一个可能有助于强制使用正确索引的选项是强制在另一个id列上使用“计算”值，这样引擎可能无法与索引直接相关...类似

WHERE field2_id = 12345 and id > 13314313

更改为

WHERE field2_id = 12345 and id + 0 > 13314313

为什么MySQL决定错误的索引？

2 个答案: