我们看到许多客户的系统因为SQL及数据库设计的很差所以导致许多性能上的问题,这些问题不好解决,但是可以采用一套简单的策略来检查生产系统,发现并纠正一些共性问题。

很显然,您应该尽最大努力设计出最好的数据库,使其有很好的索引并在应用程序中采用高质量的SQL查询语句。但是,在很多时候,现实与设计还是有很大的差异,这是因为网络应用程序开发速度快,再加上更新速度也很快,所以,数据库所连接的进程数也经常发生变化。

不幸的是,现在服务器运行速度很快,这些问题不容易察觉,只有当系统投入运行一段时间,随着用户和数据的增加,才发现问题。表中若只有10,000行的时候,任何系统都能运行的很好,但是,当表中有数百万行而SQL又很差的时候,系统就会出现问题。随着并发用户数量增多,会发出更多的并发查询,而这些查询要阅读数百万行。

接下来发生的事就不尽人意了,因为服务器会运行的很慢,像蜗牛在爬,而每个查询要花好几秒的时间才能完成任务,这样毫不费力就能使网站垮掉。这就是所谓的“瓶颈”,指的是系统一直运行的很好,但突然有一天跨了。现今,有很多系统都会出现这样的问题。

要找出问题所在并不容易,但是可以运用一些好的工具来帮忙查找问题。首先,最管用的工具就是slow log,可是,标准工具(mysqldumpslow)不会给出最重要的统计数据 – 已检查的行数。要监控系统性能,这些所谓的重要的服务器统计数据根本就算不上是好数据。请注意,还有其它的好工具,如Percona的 pt-query-profiler就很管用。

当你发现SQL遇到问题,检查出有很多行的时候,你可以在这些SQL查询中,运行EXPLAIN EXTENDED命令。尽管该命令输出的内容比较复杂、难以理解,但是,你可以通过网络资源或像Percona这些工具的帮助,就可以理解命令内容。

但是,如果是一些像我们所看到的简单查询的话(只有单个查询,不含子查询,这些查询由于临时表的存在可能会有很多行/表及联接)输出结果还是容易解释的。

检查EXPLAIN EXTENDED的输出内容(EXTENDED是比较重要的命令,因为该命令可展示许多额外信息),我们会发现很多关键信息: Type这一列很重要,如果输出结果是All或索引,它将会要求扫描所有的表或索引。

Keys这一列也很重要,因为它告诉你使用了哪个索引,如果此处为空,表示未使用任何索引,绝大多数情况下,您需解决此问题。

Rows这一列告知您数据库即将要阅读的行数,当然,越少越好。从理论上来讲,这些未阅读的行数经阅读之后,会被记录到日志中成为已检查的行数,但是实际将要阅读的行数和EXPLAIN系统所记载的将要阅读的行数可能会有差异,这是因为EXPLAIN系统的行数只是预估的行数。请注意此处不包括LIMIT,但是LIMIT不会使要阅读的行数减少,尤其是查询中有排序要求的时候,更不会减少要阅读的行数。

通过借助在线资源及一些工具,您可更好地理解输出的结果。您将发现哪些SQL执行的比较慢及根源是什么,在此,您可以更改SQL、更改索引甚至是更改数据库设计以便提高系统性能。