问题标签 [mysql-slow-query-log]

我有一个 wordpress 博客，我的共享托管公司警告我活动缓慢。

在我的 mysql slowlog.log 中，我有大约需要 2 和 3 的基本查询（我认为秒而不是毫秒）

这是日志中的查询：

我的问题是：这个查询是核心查询吗？在这种情况下需要 3 秒是正常的吗？如果没有，我该如何补救？如果它不是生成此查询的插件或主题函数，我的意思是核心查询，因为我没有在主题的 function.php 中找到它

我在日志中有另一个慢查询：

这里有同样的问题，它是核心查询还是插件相关的等等......

请注意，我已经安装了 WP 超级缓存，我的网站加载速度更快，但在 slowlog.log 中仍然有这些慢查询

PS：我在一家可靠的 hsting 公司 (infomaniak)，他们已将我的博客放在专用 VPS 机器上 15 天让我解决问题

感谢您的帮助，并为我的英语非常糟糕感到抱歉

- - - - - - - - - - - - - - - - - - - - - -编辑 - - - ---------------------------------

安装 wp 超级缓存后，这些查询再也没有办法了 :(

我有以下查询

解释扩展给出以下结果。

此查询大约需要 100 秒才能执行

Sql Slow 有以下结果

请指导我如何使其快速。提前致谢

我想知道是否有可能记录（或以另一种方式检测）一个查询，一旦它达到 long_query_time，它就会花费太多时间来执行。因为 MySQL 只在它们完成执行时记录慢查询。

我知道我可以通过检查 MySQL 管理员的“服务器连接”选项卡在完成之前看到缓慢的查询，但我希望在它发生时自动收到通知（使用日志更容易）。

使用以下参数激活慢查询日志：

现在似乎 MySQL 只记录没有索引的查询

这是一个日志样本

但是，此查询已优化。

我在 MySQL 文档中看到了这个警告：

但...

1. 我不明白记录的查询是否正确，或者我有可以修复的优化问题
2. 万一这个查询是误报，有没有办法避免那个mysql日志呢？

似乎 MySQL 将所有包含 UNION 的查询都记录为无索引查询，我对其进行了搜索，但什么也没找到。

有什么想法吗？感谢提前米歇尔

这是统一医学语言系统 (UMLS) 查找与规范化单词相关的单词的查询。此查询结果为 165 毫秒，但如果我正在运行同一查询的 VIEW，则需要 70 秒。我是mysql的新手。请帮我。

询问：

查看定义：

从视图中选择：

我有下面的代码，它返回 10 个条目。现在好像很慢。

我在患者表中有 12,107 个条目在患者保险表中有 2,296 个条目

它是一个至强 2 处理器的 linux 服务器，具有 16GB 内存。本地托管

嗨，我是这个网站的新手，我现在非常感谢你们希望你们能给我的帮助。我也是 mysql 环境的新手。所以，我的教授告诉我要找到一些工具，这些工具在输入日志文件（一般或慢查询）中给出，在 mysql 服务器上重现所有查询，如选择、删除、更新和插入。该工具可能应该是多线程的。我找到了 mysql workbench 或 mk-log-player 之类的东西，但我不确定这是否是我想要的，因为正如我在 mysql 环境中的新手之前所说的那样。

我正在使用 mysql：5.5.31-0ubuntu0.12.04.1-log (Ubuntu)，我启用了慢日志查询，慢日志查询时间设置为 2 秒了解详细信息：

在 my.cnf 中：

这意味着任何查询都需要超过 2 秒，它将存储在 mysql 慢日志查询中。

当我使用 select sleep(1) 尝试此操作时；选择睡眠（2）；选择睡眠（3）；并查看慢日志查询，只有 sleep(2) 和 sleep(3) 保存在慢日志查询中，Query_time: #Query_time: 2.000263 和 #Query_time: 3.000278 分别。但我看到许多查询时间小于 2 秒的查询也保存在慢日志查询中

更多细节 ：

为什么这种类型的查询保存在我的慢日志中，我不明白？

我有这个查询：

并解释退货

你能帮我优化一下吗？这个查询现在大约需要 7-9 秒 :( 我不是 mysql 优化专家，我不知道该怎么做......

所以我对慢查询日志的理解是它记录了我们在 my.conf 文件中设置的所有那些花费 >= 时间（以秒为单位）的查询的信息。

现在让我们采用 3 个不同的 SELECT 查询的 3 个案例（针对具有 INNODB 引擎的表）：

查询 I： Query_time：32.937667 Lock_time：0.000081 Rows_sent：343 Rows_examined： 12714043

QUERY II： Query_time：12.937667 Lock_time：0.000081 Rows_sent：43 Rows_examined： 714043

QUERY III： Query_time：42.937667 Lock_time：0.000081 Rows_sent：18 Rows_examined： 483

对我来说，QUERY I 和 QUERY II 看起来都可能是查询错误或索引不佳（或缺少索引）或碎片表数据等（我可能错过的任何其他情况？），用户可能会考虑改进查询执行时间.

但是对于 QUERY III，我无法理解，我的意思是数据库可能真的出了什么问题，它需要 42 秒来检查 483 行并发回其中的 18 行（锁定时间可以忽略不计）。当我看到它间歇性地发生时，这变得更加令人困惑。

所以我在这里真正想问的是：

• 我应该如何解释锁定时间信息？这是否意味着查询必须等待那么多秒才能真正开始执行？如果是，那么在我的示例查询 III 中实际上花了 42 秒来检查 483 行并发回其中的 18 行？
• 如果锁定时间可以忽略不计，但查询时间仍然非常巨大，只有几百行被检查并发回，我应该从哪里开始寻找问题？
• 可能是查询在某些后台 IO 活动中花费了很多时间吗？说日志记录或bin-logging。
• 表的大小对查询性能的影响有多大？例如，我们可以说 MySQL 足以处理 200+百万行的表吗
• 有没有更好的工具或方法来监控数据库活动，专门用于计算数据库的后台活动？简而言之，要检查查询花费大部分时间的位置。

可能有很多因素会影响这种缓慢的查询，所以如果你觉得你需要更多的信息来帮助我，那么请告诉我。