MySQL 查询随机滞后

Posted 2023-02-24

技术标签:

【中文标题】MySQL 查询随机滞后【英文标题】：MySQL Query Randomly Lags 【发布时间】：2014-01-02 14:37:54 【问题描述】：

我的查询如下所示：

SELECT id FROM user WHERE id='47'

使用分析数据时，此查询的 ID 已编入索引并且读取速度总是很快。

SET profiling = 1;
SHOW PROFILES;

查询总是在 0.0002 秒左右执行。

但是，如果我从 php 端分析查询，如下所示：

$current = microtime(true);
$data = $conn->query($full_query);
$elapsed = microtime(true) - $current;

然后偶尔可能有 50 个查询中的 1 个需要大约 0.2 秒。但是，在我的测试脚本中，我有代码来测试它，它使用 SET profiling = 1; 来分析查询。即使通过 PDO 的 PHP 往返行程可能是 0.2 秒，但查询时间仍然是 0.0002。

我知道或知道不会导致问题的事情：

查询并不慢。当我从同一个查询运行中查看相同的查询时，在 PHP 中进行分析并使用 SET PROFILING 进行分析时，查询总是很快并且从未记录在慢查询日志中，即使它显示从 PHP 端需要 0.2 秒。李> 这与 skip-name-resolve 无关 - 这是不一致的，我已经启用了 skip-name-resolve 这与查询缓存无关，这两种行为都存在即使查询从缓存中出来，也会发生这种行为。该查询实际上并未选择 ID，但我使用此查询进行测试以表明这不是磁盘访问问题，因为该字段肯定已编入索引。这个表只有 10-20 兆，索引类似于 1 兆。机器显示的负载非常小，并且 innodb 没有使用它的所有缓冲区。这是针对除我的测试查询之外没有其他活动的表进行测试的。

有人知道还有什么要检查的吗？在我看来，这似乎是一个网络问题，但我需要能够看到它并找到解决它的问题，而且我已经没有地方可以检查了。有什么想法吗？

【问题讨论】：

是否有可能另一个进程正在获取表上的读锁？整数上的单引号是完全可以接受的，mysql 解释得很好。 Brian，这对我来说很重要，因为在处理 mySQL 的 15 年中，我从未见过如此不稳定的查询行为，并且您引用的 50 个负载中的 1 个只是我上面所说的。这并不总是这个比例。我知道您没有完整的背景信息，但我们每月为数百万个唯一用户提供数百万个页面。这些性能比变得很重要。我不是来这里问是否有问题，我是来问是否有人对我已经确定的问题有解决方案。 +1 仅针对此问题的提问方式。遵循规则提出的问题是如此罕见。请在 2 天后提醒我 - 我会悬赏这个问题。否则它永远不会受到关注。你可以通过简单地使用另一个 api 运行相同的查询来验证网络问题，例如旧的 mysql。 【参考方案1】：

我会分析机器。

您说这种情况每 50 次发生约 1 次，并且每个查询都有 0.2 秒的基准。您应该能够将 top 放在屏幕上，然后在 PHP 中运行循环查询以对 RDBMS 进行负载测试并收集性能统计信息。

您可能必须运行超过50 * 0.2 =10 seconds，因为您的“50 分之一”统计数据可能基于手动运行的单个查询 - 基于我读到的内容你的描述。尝试 30 秒和 90 秒的负载测试。

在此期间，请注意您的 top 进程屏幕。按P 按CPU 对其进行排序。每次您按“P”时，它都会更改进程 CPU 消耗的排序顺序，因此请确保您将最消耗的排在最前面。（按M 按内存使用情况排序。查看the man page 了解更多信息）

在负载测试期间寻找任何浮出水面的东西。您应该会看到更高的东西跳动 - 但只是暂时的。（请注意，这样的过程可能不会到达列表的顶部 - 它不需要，但仍然可以引入足够的磁盘负载或其他滞后于 MySQL 服务器的活动）

【讨论】：

【参考方案2】：

我在我的系统上发现了同样的现象。通常需要一毫秒的查询会突然需要 1-2 秒。我的所有案例都是简单的单表 INSERT/UPDATE/REPLACE 语句 --- 不在任何 SELECT 上。没有明显的负载、锁定或螺纹堆积。

我曾怀疑这是由于清除脏页、刷新磁盘更改或某些隐藏的互斥锁造成的，但我还没有缩小范围。

也排除了

服务器负载——与高无关

加载引擎——发生在 InnoDB/MyISAM/Memory MySQL 查询中

缓存——无论是打开还是关闭都会发生

日志轮换 -- 事件中没有相关性

【讨论】：

您好，您找到问题的原因了吗？我在一家英国托管公司的 CentOS 虚拟服务器上遇到了类似的问题。我只是运行一个只有 INNODB 表的数据库，使用简单的查询，大多数时候一组 12 个查询总共需要 15 毫秒来执行，但有时它们需要 300 毫秒，甚至 1 个查询可能需要 1000 毫秒。有很多 RAM ，启用缓存，线程池正常。 MySQL 服务器和 PHP 服务在同一台服务器上。我唯一想到的是虚拟化做得不好或者硬件可能有故障。【参考方案3】：

您已经在使用查询分析器了。如果您使用的是 MySQL 5.6，您还可以访问 PERFORMANCE_SCHEMA 中的许多新性能测量。与查询分析器相比，它具有测量更多细节的能力，并且它还可以全局测量，而不仅仅是一个会话。据报道，P_S 将取代查询分析器。

要诊断您的问题，我会先确认或排除 TCP/IP 问题。例如，测试 PHP 脚本以查看它在通过 UNIX 套接字连接时是否获得相同的间歇性延迟。您可以通过连接到localhost 来执行此操作，这意味着 PHP 脚本必须在与数据库相同的服务器上运行。如果绕过 TCP/IP 后问题消失，这将告诉您根本原因很可能是 TCP/IP。

如果您处于云托管之类的虚拟环境中，您很容易会遇到性能变化，因为同一云的其他用户会间歇性地耗尽所有带宽。这是云的缺点之一。

如果您怀疑这是 TCP/IP 问题，您可以独立于 PHP 或 MySQL 测试 TCP/IP 延迟。现有的典型工具包括ping 或traceroute。但是有many others。你也可以test network speed with netcat。使用可以随时间重复测量的工具，因为听起来您大部分时间都表现良好，偶尔会出现故障。

另一种可能是问题出在 PHP 上。您可以尝试使用 XHProf 分析 PHP 以了解它在哪里花费时间。

【讨论】：

【参考方案4】：

尝试隔离问题。像这样运行一个小脚本：

https://drive.google.com/file/d/0B0P3JM22IdYZYXY3Y0h5QUg2WUk/edit?usp=sharing

...查看链条中的哪些步骤正在飙升。如果您安装了ssh2，它还会在运行时间最长的测试循环之后立即返回ps axu，以查看正在运行的内容。

在我家开发盒子上运行localhost，结果如下：

ps axu 这里的结果非常没用，因为我正在连接到 localhost。但是，我可以从这些结果中看到，数据库连接延迟偶尔会出现峰值，“网络”延迟（一些 TCP/IP 缓冲区？）也是如此。

如果我是你，我会将测试周期数增加到 5000 或 50000 个。

【讨论】：

【参考方案5】：

我只能猜测，但是由于您消除了服务器负载，并且我假设您检查了 InnoDb-Stats 中的危险信号（phpmyadmin 对此有很大帮助，尽管有更专业的工具），剩下的是密钥的不一致使用。会不会是您的查询略有不同，并且存在使用次优索引的星座？

请添加FORCE INDEX PRIMARY 或类似的重复您的测试。

【讨论】：

【参考方案6】：

mysqltuner 是我发现在诊断 MySQL 问题方面非常有用的东西。这是一个 PERL 脚本，它查看您的 MySQL 实例并建议各种调整改进。老实说，很难跟踪您可以执行的所有调整，而这个脚本非常棒，可以为您提供潜在阻塞点的细分。

另外需要考虑的是 Linux 本身是如何工作的，这也可以解释为什么你会随机滞后。当您在 Linux 机器上加载top 时（任何机器，无论负载如何），您会注意到您的内存几乎完全被使用（除非您刚刚重新启动）。这不是您的盒子的问题或超载。 Linux 尽可能多地加载到 RAM 中以节省时间并将不经常使用的东西交换到交换文件中，就像所有现代操作系统（称为虚拟 RAM）一样。通常没什么大不了的，但您可能使用InnoDB 作为表类型（当前默认值），它会将内容加载到 RAM 中以节省时间。可能发生的情况是您的查询已加载到 RAM 中（速度很快），但闲置的时间刚好足以换出到交换文件（慢得多）。因此，当 Linux 将其移回 RAM 时，您会受到很小的性能影响（交换文件在这方面比 MySQL 将其从磁盘中移出更有效）。 MySQL 和InnoDB 都没有办法说明这一点，因为就他们而言，它仍然在 RAM 中。该问题在this blog上有详细描述，相关部分为

通常少量的交换使用是可以的（我们真的很担心关于活动——交换进出），但在许多情况下，“真正”有用内存正在被交换：主要是 InnoDB 缓冲池的一部分。什么时候再次需要它，需要很大的性能才能将其交换回来 in，导致随机查询的随机延迟。这可能导致整体生产系统上不可预测的性能，并且通常是一次交换开始，系统可能进入性能死亡螺旋。

【讨论】：

【参考方案7】：

我们发现底层硬件的问题导致了这种情况。我们使用 VMotion 将服务器移至新硬件，问题就消失了。 VMWare 没有显示警报或硬件问题。尽管如此，离开硬件解决了这个问题。非常非常奇怪。

【讨论】：

以上是关于MySQL 查询随机滞后的主要内容，如果未能解决你的问题，请参考以下文章