MySQL 查询优化器显示对具有主索引和复合索引的表进行查询的随机行为

Question

我有一个正在执行查询的 MySQL 表。在某些情况下，查询需要花费约 15 分钟的时间才能返回结果，但在其他情况下，它会在几毫秒内返回结果。 这两个查询仅在 where 子句中的列的值上有所不同。

表语法

CREATE TABLE `tests` (
  `id` varchar(36) NOT NULL,
  `some_other_id` varchar(36) NOT NULL,
  `col_1` varchar(64) NOT NULL,
  `col_2` varchar(128) DEFAULT NULL,
  `col_3` varchar(64) DEFAULT NULL,
  `status` varchar(32) NOT NULL,
  `created_at_epoch` bigint(20) NOT NULL,
  `updated_at_epoch` bigint(20) NOT NULL,
  `updated_by` varchar(64) NOT NULL,
  `version` int(11) NOT NULL,
  `col_4` text,
  `col_5` varchar(64) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `some_other_id_col_1_col_2_idx` (`some_other_id`,`col_1`,`col_2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

id 和 some_other_id 是使用时间戳和随机字符创建的，some_other_id 的示例是“15632901521370150qGUCAQpVuUWK-bJg"

该表包含约 6000 万条记录，约 56 GB 数据。

请注意以下查询中 some_other_id 的值。

select test.id, test.col_3, test.col_5, test.created_at_epoch, test.col_2, test.col_1, test.col_4, test.status, test.some_other_id, test.updated_at_epoch, test.updated_by, test.version from tests test where test.some_other_id='**VAL_1**' and (test.status in ('activated')) and test.id>='' order by test.id limit 2;
--Executes within milliseconds.
--Explain plan gives key as "some_other_id_col_1_col_2_idx".

select test.id, test.col_3, test.col_5, test.created_at_epoch, test.col_2, test.col_1, test.col_4, test.status, test.some_other_id, test.updated_at_epoch, test.updated_by, test.version from tests test where test.some_other_id='**VAL_1**' and (test.status in ('activated')) and test.id>='' order by test.id limit 1;
--Takes ~14-15 minutes.
--Explain plan gives key as "PRIMARY".

select test.id, test.col_3, test.col_5, test.created_at_epoch, test.col_2, test.col_1, test.col_4, test.status, test.some_other_id, test.updated_at_epoch, test.updated_by, test.version from tests test where test.some_other_id='**VAL_1**' and (test.status in ('activated')) and test.id>='' order by test.id limit 3;
--Executes within milliseconds.
--Explain plan gives key as "some_other_id_col_1_col_2_idx".

select test.id, test.col_3, test.col_5, test.created_at_epoch, test.col_2, test.col_1, test.col_4, test.status, test.some_other_id, test.updated_at_epoch, test.updated_by, test.version from tests test where test.some_other_id='**VAL_2**' and (test.status in ('activated')) and test.id>='' order by test.id limit 2;
--Takes ~14-15 minutes.
--Explain plan gives key as "PRIMARY".

select test.id, test.col_3, test.col_5, test.created_at_epoch, test.col_2, test.col_1, test.col_4, test.status, test.some_other_id, test.updated_at_epoch, test.updated_by, test.version from tests test where test.some_other_id='**VAL_2**' and (test.status in ('activated')) order by test.id limit 2;
--Takes ~14-15 minutes.
--Explain plan gives key as "PRIMARY".

select test.id, test.col_3, test.col_5, test.created_at_epoch, test.col_2, test.col_1, test.col_4, test.status, test.some_other_id, test.updated_at_epoch, test.updated_by, test.version from tests test where test.some_other_id='**VAL_2**' and (test.status in ('activated')) and test.id>='' limit 2;
--Executes within milliseconds.
--Explain plan gives key as "some_other_id_col_1_col_2_idx".

我无法理解这里的行为，并且正在寻找有关如何发生这种情况的一些解释。 我使用的是MySQL 5.6

Answer 1

添加此复合索引:

INDEX(status, some_other_id, id)  -- in this order

对于 56GB 的数据，您应该认真考虑规范化和其他缩小表大小的技术。 status 是此类的主要候选者。 TINYINT UNSIGNED 仅占用 1 个字节并提供 256 个值。 ENUM 可能是一个可行的替代方案。

updated_by 是另一个可能缩小的东西。

如果这些纪元仅限于秒，请勿使用 8 字节的BIGINT。

要进一步调查性能异常，请提供每个异常的 EXPLAIN FORMAT=JSON SELECT ... 以及“优化器跟踪”。