由于 MySQL 的普及，我们不难发现有许多 MySQL 的非专业使用者，他们十分依赖 MySQL 进行日常营运但却不想(也不打算)进一步的成为 MySQL 专家，对他们而言只要可以用就好了。当与 Query 相关的效能瓶颈出现时，这些使用者将没有能力解决所糟遇的难题，因为在这世界上并不存在对于 Slow Query 的通用解决方案；你所糟遇到的所有情况都是独一无二的。
此份文件并非技术文件，而是记载辨识 MySQL Slow Queries 的一般性原则。你不需要是 MySQL 专家、也不需要知道如何分析 Query，也可以懂得如何辨识出对系统效能产生最多影响的 Slow Query。一但你辨识出这些 Queries 后，你就可以求助于 MySQL 专家来解决此问题。
一、建立基准(Baseline) 在你对 MySQL Server 进行任何改变之前，一定要先建立目前 MySQL Server 的效能基准，不然的话你就无法得知后续对于 Server 的调校是否真的可以提升效能。要建立基准的最简单方式就是使用 mysqlreport，你只要先让 MySQL Server 至少先运作个一整天然后再使用 mysqlreport 产生分析报表即可掌握 Server 目前的运作状况。如果你没办法让 MySQL Server 至少运作个一整天，那么产生出来的报表可能会具有偏误、比较不具代表性。
二、评估基准 mysqlreport 所产生出来的报表包含有非常多的资讯，但我们目前只需要关注在其中三项即可。首先要看的是 "Read ratio" (line 6 or 7)，它应该要低于 0.01，若它超过 0.01 你就必须要分配多一点的 RAM 给 MySQL Server 使用。务必要确定系统有足够的 RAM 可使用，若系统整体的 RAM 使用量已超出负荷，然后你又调高 MySQL 可使用的 RAM 上限，将会造成 MySQL 不断地进行 SWAP 而让问题变得更严重。
接下来要看的是 "Slow" (line 16)。Slow 表示 Slow Queries 的数量，系统预设将执行时间超过 10 秒的 Query 判定为 Slow Queries，而这个项目的最后一个栏位之数值应该要低于 0.05，若它高于 0.30 你八成会发现系统有些很明显的问题发生。我们必须要尽全力地去降低 Slow 的数值。
最后一个要注意的项目是 "Waited" (line 48)，尤其是最后一个栏位的数值。这个数值表示 MySQL 需要等待以取得 Table Lock 的次数之多寡，通常这个数值会低于 10%，若是它超过 10% 通常是因为 Slow Queries 所造成的。
你并不需要了解这些数值所代表的详细意义，但是它们的确让我们对于 MySQL 的运作状况有一个整体的概念。若是这些数值偏高，那么负责处理这些问题的 MySQL 专家将可以很容易的就找出问题点；但若是这些数值偏低，但 MySQL Server 却运作的十分没有效率，MySQL 专家们应该还是可以找出确切的问题点。
三、记录 Slow Queries 并且等待 MySQL 预设并不会记录 Slow Queries，你必须要修改 MySQL Server 的系统设定档，例如 /etc/my.cnf:
引用: 重新启动 MySQL 并且等待至少一整天的时间，MySQL 将会记录所有执行时间超过一秒的 Slow Queries。Slow Query Log 的档案名称预设是 slow_queries，它们会存在 MySQL 的 Data Dir 之中，若是你不知道 MySQL Data Dir 在什么地方，可以在登入 MySQL 指用以下的指令来找出："SHOW VARIABLES LIKE 'datadir';"。在 Linux 系统中它通常会是 /var/lib/mysql/，因此 Slow Query Log 就会是 /var/lib/mysql/slow_queries.log。
四、辨识出 Top 10 Slow Queries 要辨识出 Top 10 Slow Queries 的最简单方式就是使用 mysqlsla 来分析 slow loq，你可以将 mysqlsla 所产生出来的报表交给 MySQL 专家，让它们协助你解决问题。在大部份的情况下，就算是只有 Top 3 的 Slow Queries 可以被克服，MySQL Server 的整体效能仍然可能会有大幅度的提升。从这里开始，之后的工作就要交由 MySQL 专家来处理。
五、确认系统效能是否已改善 假设您的 MySQL 专家具有解决 Top Slow Queries 的能力，那么你的最后工作就是确认系统效能已确实的改善。重新启动 MySQL 并且让它至少执行个一整天，再以 mysqlreport 来评估系统的运作效能，然后再将结果与之前的报表做比较，尤其注意第二步骤中所提到的那三个项目(Read ratio, Slow, and Waited)。这三个项目的值应该会很显着的降低才是，若没有，则进一步的向您的 MySQL 专家询问，他们将会告诉你为什么这不是一个可以轻易达成的 "simple fix"。
事先告知 当你的 MySQL Server 顺利的运转了几个星期之后同样的问题却再度发生时，不要觉得惊讶，因为效能的调校往往牵涉到许多复杂的层面，而不是单一的问题。当你今日解决了 MySQL 的效能问题后，有可能在几个月后你会需要再重新进行一次整个步骤，这不是 MySQL 的错，而是 "成长" 所造成的负作用。有可能只是单纯的因为你的资料库使用者发现 MySQL 运作的更顺畅，因此他们就更频繁的使用，而更频繁的使用就再度的加重系统的负载。当越多的负载加诸在您的 MySQL Server 上时，自然就需要越多的效能调校。
本文转贴自 http://gglog.net/blog/index.php?op=V...leId=82&blogId=1
本篇文章是由 Daniel Nichter 的
"Non-technical Guide to Isolating Slow MySQL Queries" 翻译而来。
