gpt4 book ai didi

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

转载 作者:IT王子 更新时间:2023-10-29 00:35:44 32 4
gpt4 key购买 nike

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

最佳答案

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

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

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

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

关于mysql - 为什么 MySQL 会选择错误的索引?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14414135/

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com