MySql执行路径突然变化很大，不一致，速度慢

Question

我在 MySQL 上的执行路径上遇到问题，导致查询缓慢且不一致。这是一个全新的现象。我们还有其他具有完全相同(好吧，尽可能接近)设置的表，这很好，但出于某种原因，现在创建新表会遇到这个缓慢/不一致的问题。

我们使用的版本:“mysql Ver 14.14 Distrib 5.6.31，用于 debian-linux-gnu”和 InnoDB。数据库存在于一个 vagrant box 中。

该行为在另一台计算机上重现，并且是在全新版本的 vagrant box 之后。

正如我所说，数据库在我本地机器上的一个 vagrant box 中，我的机器负载不重。

t1 有大约 100 万行。t2 是一张新表。

这是始终重现问题的最简单的查询:

SELECT
    *
FROM
    redacted_t1 AS t1
        JOIN
    redacted_t2 AS t2 ON t1.a_column = t2.id
WHERE
t2.c_column != 'asdff'
ORDER BY t1.b_column DESC;

请参阅下面一些执行路径较慢(超过 3 秒)的示例

我已经看到至少 2 个其他执行路径(它们也很慢)但是因为很难重现(随机？)我不能在这里发布它们。

有时，但不经常，我不知道如何或为什么会发生以下执行路径:

这非常快，0.00 秒。有时拥有全新版本的数据库(如在新的 vagrant box 中)，并在 t1 和 t2 上运行优化会产生此结果。有时优化什么也没做。有时这种执行状态是在没有optimize table的情况下实现的。请注意，与慢速执行路径相比，t1 的“行”计数要低得多。如果我运行“SHOW STATUS;”，这与我看到的一致。

CREATE TABLE `redacted_t2` (
  `id` int(11) NOT NULL AUTO_INCREMENT,

  -- redacted

  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci

CREATE TABLE `redacted_t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a_column` int(11) DEFAULT NULL,

  -- redacted

  PRIMARY KEY (`id`),

  -- redacted

  KEY `redacted_t1_a_column` (`a_column`),

  -- redacted

  CONSTRAINT `fk_redacted_t1_2032420404` FOREIGN KEY (`a_column`) REFERENCES `redacted_t2` (`id`),
) ENGINE=InnoDB AUTO_INCREMENT=redacted DEFAULT CHARSET=utf8 COLLATE=utf8_swedish_ci

所以我有几个问题:

1)为什么执行路径如此不一致，为什么我们以前从来没有遇到过？

2) 我们如何着手解决这个问题，使应该花费 0.00 秒的查询不会随机花费 3 秒？

Answer 1

您可以尝试运行 EXPLAIN EXTENDED，然后运行 ​​SHOW WARNINGS，以获得有关查询执行计划的更多详细信息。参见 8.8.3 Extended EXPLAIN Output Format了解详情。

您也可以尝试运行 ANALYZE TABLE在 t1 和 t2 上确保 MySQL 在选择其执行计划时使用更新的表统计信息。

在 redacted_t2.c_column 上添加索引可能会有所帮助，因为您正在对该列进行过滤。

从 EXPLAIN 输出来看，MySQL 有时似乎没有使用索引 redacted_t1_a_column。您可以鼓励或强制数据库使用带有 index hints 的索引。 ，例如USE INDEX 或 FORCE INDEX。