就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




9年前关闭。




哪个是最好的、对用户最友好的 MySQL 性能工具？我需要帮助确定我的设置的瓶颈。是 SQL 语句、设置变量还是其他方面的问题？

最佳答案

坏消息:有 GUI 工具可以帮助解决这个问题，但它是一项技能娴熟且范围广泛的工作。因此，它们并未涵盖所有内容，您可能需要使用命令行内容/sql 语句等来提供帮助。我只真正使用过命令行工具。我将概述一下我知道/使用过的东西:

首先，你需要一个好的数据库设计。如果设计不好，你只能走到这一步。这包括规范化以及对字段使用适当的类型。我将把这一点留在这里，因为我认为它有点放在一边，而不是你所追求的。

确保 MySQL 查询缓存已设置并正常工作，如果可以，请为其提供更多 RAM，并确保您的重要查询没有执行任何阻止 mysql 缓存它们的操作。例如，在查询中使用 NOW() 函数可以做到这一点 - 出于显而易见的原因 - NOW 每秒都在变化!您可以改为在 sql 中添加时间戳，并使用最接近的分钟/小时/天(您可以摆脱的最大时间段)的时间来让 mysql 获得一些缓存优势。

开始优化:在 select 前面加上“EXPLAIN”是查看查询如何执行并确定如何改进它的方法。学习解释输出:http://dev.mysql.com/doc/refman/5.0/en/using-explain.html您通常可以向现有索引添加新索引/添加列以改进内容。但是您也会遇到需要重构查询的情况。

开始使用 MySQL 提高性能(假设您还不知道问题查询是什么)是检查慢查询日志 - 它将所有查询时间超过 x 秒记录到文件中。

概述，包括配置，如果它已经没有记录，在这里:http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - 我还发现将 long_query_time 设置为 0 一天左右，以便将所有查询记录在此处，并记录所用时间，这是了解性能进展情况的有用方法。但我不会马上去那里!不要让它一直开着，日志会变得很大。

一旦你有几天的日志记录，我就从这里找到了 mysqlsla(mysql 慢日志分析器):http://hackmysql.com/mysqlsla是个好工具。

它可以做的不仅仅是慢速查询日志分析 - 阅读手册。但是要解释它对慢日志的作用:慢查询日志可以包含大量数据，因此很难确定哪些查询总体上是最昂贵的 - 例如:考虑它们运行的​​次数和两次查询的时间实际上是相同的，在 where 子句中具有不同的 id。

MySQL sla 为您完成这一切。它贯穿日志，并且可以对 where 子句中相同/具有不同值的查询进行分组。然后它会向您展示(默认情况下)总执行时间前 10 条查询 - 这通常会有一些惊喜，但通常是最高效的起点 - 选择最昂贵的查询并对其使用 EXPLAIN，看看您是否可以改进它。

有些查询需要很长时间，而且不容易改进。在这种情况下，您能否以另一种方式获取数据或至少将其缓存起来？您甚至可能会发现需要更改数据库架构。同样，某些查询可能位于 mysqlsla 输出的顶部，因为您经常运行它们(尤其是如果 long_query_time 设置为 0)，即使它们运行得非常快。也许是时候为您的应用程序添加一些缓存了？

http://www.maatkit.org/看起来也很有希望 - 从未使用过它，但 mk-query-profiler 工具应该有助于进一步研究查询缓慢的原因。

一个完全独立的东西也要看:PHPMYADMIN中的“状态”页面(或者你可以运行所有查询来生成这个信息......) - 它用红色突出显示它认为可能不好的东西，并且可以帮助你查看您可以从分配系统资源中获得哪些好处。我对此知之甚少 - 我的方法一直是，如果某个东西是红色的并且看起来很糟糕，那就去阅读它并决定它是否重要以及我是否应该做某事(通常意味着将更多资源分配给 MySQL通过更改配置)。

最近，我发现运行 SHOW PROCESSLIST 在遇到问题的服务器上也很有用。虽然它只为您提供实时(嗯，实时快照)信息，但它可以帮助您了解在给定时间发生的情况，尤其是在您刷新几次并观察更改时。我最近发现一个服务器使用每个可用的 mysql 连接来使用这种方法运行相同的查询。当然，它会出现在慢查询日志中，但这是一种非常快速且明显的查看发生了什么的方式。

https://stackoverflow.com/questions/362223/