非技术性 MySQL慢查询指南

原文： http://hackmysql.com/nontech

     MySQL是无处不在，因此，有许多非技术性用户依赖于MySQL，但又不是MySQL的专家。当出现查询相关的性能问题时，这些用户都处于无助状态，因为没有灵丹妙药来处理慢查询，每一种情况下是独一无二的。

     这篇文章是一个处理慢查询的非​​技术性用户指导。你不必是MySQL专家，或知道如何分析查询语句，隔离（即识别）哪个查询语句造成您的服务器问题。一旦你已经分离出了这些查询语句，就可以与MySQL专家咨询如何解决这些问题。（ps：你只需要按照这个指南提取出有问题的查询语句，剩下的就交给专家去处理吧。）

第一步：基线

     作出任何改变之前，总是要先建立MySQL性能基线。否则，它是真的只是一种猜测（是否提高MySQL性能的变化）。提取MySQL基线性能的最简单的方法是用mysqlreport。让MySQL的运行至少一整天，然后运行mysqlreport --all ，并保存报告（它可以很容易的通过电子邮件发送自己做的报告：mysqlreport --all --电子邮件 --user xxx --password xxx）。如果MySQL没有持续运行一天以上时，尝试运行某些引起性能变化的应用，并运行足够的时间来暴露问题。

2。评估基线

mysqlreport写的报告包含了大量的信息，但我们的目的只有三件事情需要关注。 （一个的mysqlreport报告能够让你充分理解mysqlreport这个工具）。

首先是“Read ratio”（第6或7行）。这个应该不超过0.01。如果超出的话，MySQL需要进行配置，确保MySQL可以使用更多的RAM。如果您的系统内存太少，MySQL没有足够的RAM，MySQL会尝试使用交换分区，（使用硬盘空间作为RAM）通常使问题变得更糟。

     下一个值在第16行，“slow”，是指慢速查询。 10秒的默认时间后查询被认为是缓慢的，如果它需要更长的时间来执行,此行的最后一列和值（如“％的DMS：0.44”）一般应小于0.05。你可能会注意到这个值在0.30之上。这就是我们正在努力减少的地方。

     最后一个我们要注意的值是“Waited,”在第48行，特别是最后一列和值（类似“%Total：0.27”）。这个值是说必须等待得到锁权限的锁表数量。锁定是在这么多的用户同时获取MySQL的共享数据。此值应小于10％。如果不是，通常是慢查询产生的原因了。

这是没有必要了解这些价值观在这一点上的性质，但这些值会给我们一个想法。如果这些值很高的话，那么MySQL专家将有一个简单的工作。如果值低，但MySQL是确实运行速度很慢，你的MySQL专家仍然能够确定为什么会出现这些问题。

3。记录慢查询和等待

     默认情况下的MySQL的慢查询时间为10秒。需要修改时间的话就在/ etc/my.cnf的 [mysqld]部分中加入：

log-slow-queries

long_query_time = 1

重新启动MySQL，等待至少一整天。这会让MySQL来记录所有查询时间超过1秒的查询语句。

慢速查询日志文件名称是slow_queries.log（默认），位置在你的MySQL 程序的 data 目录中。如果你不知道你的MySQL data 目录，登录到MySQL并执行“SHOW VARIABLES LIKE 'datadir';“。这将显示你的MySQL目前正在使用的数据目录。一个典型的Linux系统的数据目录是/ var/lib/mysql 。因此，慢查询日志是/var/lib/mysql/slow_queries.log。

4。识别top10慢查询

     识别慢查询日志中排名前10位的查询的最简单的方法是使用mysqlsla。运行mysqlsla ，将结果输出保存到一个文件。例如：“mysqlsla --log-type slow /var/lib/mysql/slow_queries.log > ~/top_10_slow_queries”。该命令将在你的home目录中创建一个 top_10_slow_queries 文件。这个文件是你将要给MySQL专家看的。在大多数情况下前3名的慢查询，如果是可以被修复的，你的MySQL和服务器的整体性能会急剧提升。从这里的的谚语球是在MySQL专家的法院。

5。修复后证明

     假定你的MySQL专家能够解决大多数的慢查询，最后一步是证明这种情况不只是巧合。重新启动MySQL和等待足够长的时间，让MySQL运行了第一步（至少一天）。然后用mysqlreport再次得到MySQL的基线性能报告。比较这二份报告，特别是（Read ratio, Slow, Waited）三个值的变化。应该有这三个值明显减少。如果不是，进一步与MySQL专家协商，他们应该能够告诉你，为什么这种情况下不是一个“简单的修改”。

预警

     如果你的MySQL服务器需要在几个月内再次做这样的处理，不要惊慌。性能问题是一个复杂的问题，上面那些做法是可以提高性能的。我经常看到mysql的性能调整后，几个月里再次出现问题的案例。这不是一个MySQL的故障，而是经济增长的副作用。当你的数据库的用户发现它运行得很好的时候，他们会更多地使用它。也许更多的新用户开始使用它。随着越来越多的需求，你的MySQL服务器将需要更多的优化。