Question

我有一个如下所示的查询：

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;

然后偶尔这些查询中有一半可能会花费0.2秒。但是，在我的测试脚本中，我有代码来测试它，使用SET profiling = 1来描述查询;即使PHP通过PDO往返可能是0.2秒，查询时间仍然是0.0002。

我知道的事情，或者知道没有引起问题：

查询速度不慢。当我查看相同的查询时，从同一个查询运行，在PHP中进行分析并使用SET PROFILING进行分析，查询总是很快，并且永远不会记录在慢查询日志中，即使它显示从PHP端获取.2秒。
这不是与skip-name-resolve相关的 - 这是不一致的，我已经在上面使用skip-name-resolve
这不是与查询缓存相关的，
即使是从缓存中发出的查询，也会发生此行为。
查询实际上并未选择ID，但我使用此查询进行测试，以表明它不是磁盘访问问题，因为该字段已明确编入索引。
这张表只有10-20 megs，类似1 meg索引。机器显示非常小的负载，并且innodb没有使用它的所有缓冲区。
针对除了我的测试查询之外没有其他任何活动的表进行测试。

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

Answer 1

我会描述一下这台机器。

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

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

在此期间，请观看top进程屏幕。按P按CPU对其进行排序。每按一次'P'，它将改变进程CPU消耗的排序顺序，因此请确保您的消费最多。（按M按内存使用情况排序。请查看the man page以获取更多信息）

在负载测试的时间内寻找任何冒泡的东西。你应该看到跳跃更高的东西 - 但是暂时 （注意，这样的过程可能无法到达列表的顶部 - 它不需要，但仍然可能引入足够的磁盘负载或其他活动来延迟MySQL服务器）

Answer 2

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

我曾怀疑这是因为清除了脏页，刷新磁盘更改或隐藏的互斥锁，但我还没有将其缩小。

也排除了

服务器负载 - 与高
加载引擎 - 使用InnoDB / MyISAM /内存MySQL查询
缓存 - 无论是开启还是关闭
记录轮换 - 事件中没有相关性

Answer 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进行分析，以找出它花费时间的位置。

Answer 4

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

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

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

在我的家庭开发盒上运行localhost，结果如下所示：

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

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

Answer 5

我只能猜测，但是由于你消除了服务器负载，我认为你在InnoDb-Stats中检查了红旗（phpmyadmin对那个有很大的帮助，尽管有更专业的工具），剩下的是密钥的不一致用法。可能是您的查询略有不同，并且存在使用次优索引的星座？

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

Answer 6

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

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

通常一点点交换使用都可以（我们真的很担心关于活动交换进出），但在很多情况下，“真实”有用正在交换内存：主要是InnoDB缓冲池的一部分。什么时候再次需要它，一个重大的性能打击来换回它 in，导致随机查询中的随机延迟。这可能导致整体在生产系统上无法预测的性能，通常是一次交换开始，系统可能会进入性能死亡螺旋。

Answer 7

我们发现底层硬件的问题导致了这个问题。我们使用VMotion将服务器移动到新硬件，问题就消失了。 VMWare未显示硬件警报或问题。尽管如此，硬件的一个举措解决了这个问题。很奇怪。

MySQL查询随机丢失

7 个答案: