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

我们的数据库已设置好，因此我们有一个credentials包含多种不同类型凭据（登录名等）的表。还有一个credential_pairs表将其中一些类型关联在一起（例如，用户可能有密码和安全令牌）。

在尝试查看一对是否匹配时，有以下查询：

此查询工作正常，并为我们提供了我们所需要的。但是，它不断显示在慢查询日志中（可能是由于缺少索引？）。当我要求 MySQL“解释”它给我的查询时：

我有一种感觉，最后一个条目（它显示 69197 行）可能是问题所在，但我与 DBA 相差甚远......帮助？

凭证表：

credential_pairs 表：

凭证索引：

credential_pair 索引：

更新说明：

AFAICT：DISTINCT 是多余的……没有什么真正需要它，所以我放弃了它。为了遵循 Fabrizio 的建议，在 credential_pairs 查找中找到位置，我随后将语句更改为：

没事了。该语句需要同样长的时间，并且解释看起来几乎相同。因此，我在主列和辅助列中添加了一个索引：

没事了。

它说它正在使用索引，但它看起来仍然像是在扫描表。因此，我添加了一个联合密钥（根据下面的 a'r 评论）：

而且...与索引相同的结果（这些功能是否相同？）。

我有一个应用程序已经运行了很长一段时间，但最近一些项目开始在慢查询日志中弹出。所有查询都是可以使用重构的复杂且丑陋的多连接选择语句。我相信它们都有斑点，这意味着它们被写入磁盘。让我好奇的部分是为什么他们中的一些人有与之相关的锁定时间。所有查询都没有应用程序设置的任何特定锁定协议。据我所知，除非明确指定，否则默认情况下您可以读取锁。

所以我的问题是：什么情况下会导致 select 语句必须等待锁定（从而在慢查询日志中报告）？假设 INNODB 和 MISAM 环境。

磁盘交互是否可以列为某种锁定时间？如果是的话，周围有没有说明这一点的文件？

提前致谢。

我有以下数据库结构：

此表（业务）有 507,736 条记录

此表（businesscat）有 519,825 条记录

此表（类别）只有 5 条记录

所以，我的问题是我正在尝试使用 ff 计算最近的业务来获取 100 条记录：

任何想法让它更快？

如果您正在尝试诊断 mysql 后端中的慢查询并且正在使用 Django 前端，那么如何将后端报告的慢查询与 Django 前端代码中的特定查询集联系起来？

是否有一些配置可以在 MySQL 端自动终止或超时非常慢的查询，比如 100 秒。

我在我的服务器中启用了 mysql 慢查询来记录需要超过 5 秒的查询。当我从 mysql> 运行相同的查询时，报告超过 10 秒的查询用时不到 1 秒。这是为什么？

TIA，-彼得

我正在尝试使用我没有制作的脚本解决一些问题，该脚本似乎/tmp很快就填满了 mysql 目录。

我检查了slow query log它，它有很多这样的查询..

除了我相信45总共有工会（每个类别表 1 个）之外，这些表并不大，但该Advertising_Business_and_Retail表本身就有关于450k列表的信息。

我手动运行了这个查询，大约花了 2 分半钟。

我猜这就是为什么 /tmp 目录填得这么快的原因？

关于我可以做些什么来解决这个问题的任何提示？

我想优化我的 mysql 数据库，因此在 my.cnf 中启用了 mysql 慢查询开关。我看到的是许多 sys_log 查询，其中包含来自我的扩展或其他扩展的许多表。这是一个慢查询吗？我怎样才能超越它？

我有以下程序：

这里是CREATE TABLE表格Teams和脚本team_project：

我在服务器上几乎没有具有相同架构的数据库，但只有当它被一个数据库调用时才会记录此过程。那些其他数据库完成的调用没有被记录。这不是查询慢或慢的问题（它总是需要大约 0.0001 秒）。这就是为什么它被记录为不使用索引。这怎么可能？

正如 Zagor23 建议EXPLAIN的那样，我运行它，这是结果。a) 在记录过程的数据库中：

b) 数据库，其中未记录过程：

事实是 - 数据有点不同，但差别不大。GoodDB（不记录 proc）在 Teams 中有 11 行，在 team_project 中有 420 行，BadDB - 在 Teams 中有 4 行，在 team_project 中有大约 800 行。看起来不像是出价差异。有没有办法避免记录该过程？

我在生产机器上有以下设置：
Mysql server 5.5.19
the active（检查 ps 行）my.cnf 包含：

mysql> 显示变量，如“log%”；--> 显示“log_queries_not_using_indexes=ON”和“log_slow_queries=ON”

文件 /opt/app/mysql/log/mysqld-slow.log 存在，属于 mysql，长度为零。

问题是，在测试机器上，由于 log-queries-not-using-indexes 选项，我们的 eslow 查询日志迅速填满。我们禁用了它，因为它无论如何都需要。现在我们刚刚使用我们的生产数据库并希望确保同样的事情不会发生在我们身上，并找到了相同的设置，但日志是空的。我们不能只是重新启动 mysqld 并到处玩，因为我们现在还活着。我只是想了解为什么日志是空的，尽管配置似乎表明它应该记录lotsa 查询。在生产和测试服务器上运行的一般应用程序是相同的，因此实际上不太可能没有发生未索引的查询。

所以问题是：我可以检查哪些其他配置以查看为什么没有记录任何内容？我不希望它被记录，我只是想确保如果由于某种原因重新启动数据库服务器，它不会突然开始疯狂地记录。我知道我可以通过简单地从 my.cnf 中删除该选项来实现这一点，但我也想了解为什么它现在没有记录。

谢谢，伊桑