【发布时间】：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。