我们看到许多客户的系统因为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、更改索引甚至是更改数据库设计以便提高系统性能。
（Authored by Steve Mushero / ChinaNetCloud CEO & CTO 本博客英文原文请点此查看）