11

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

2 回答 2

4

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

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

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

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

于 2013-01-28T12:34:38.177 回答
1

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

WHERE field2_id = 12345 and id > 13314313

变成

WHERE field2_id = 12345 and id + 0 > 13314313
于 2013-01-28T12:21:26.690 回答