大家应该都遇到过WEB应用数据库访问慢的问题，如果只是少量的页面访问有问题（性能问题）时，优化是非常简单的。但是如果是“所有的都慢”，需要如何做呢？

看那些来自于数据库并且在页面上显示的信息。这是重要的，因为这些信息是需要用这样或那样的方法从数据库中读取出来的，如果确实是打算这样显示的话。任务就是要使用最高效的方法，从数据库中得到这些信息。

考查这些信息的动态性。如果很少改变，或者干脆就是静态的，那么比较好的方法是预先创建（pre-create）或者缓存它。只是要记住，优化数据库访问的最好的方法，就是避免访问数据库。这对于其他的类似事情也适用----如果可以完全避免动态页面的产生，并且使用服务器的缓存来解决，就更好了。

检查从数据库读出的数据与需要显示的信息是否相符。从数据库出读取的信息，往往比生成页面所需要的信息要多。轻一点的像是SELECT*FROMtbl，而不是只列出那些真正需要的列；严重的可以是用SELECT*FROMtbl来计算表中有多少行记录（不是开玩笑）。有时候会看到查询了100个stories，其中任一个会被选择显示出来，由应用程序层做过滤。有时候在应用程序层这样做是高效的，但是通常应该使查询只返回需要的信息。

检查结果集的记录数。这是非常重要、而且经常被遗忘的步骤。如果一个查询返回很少的行数，有些人就认为它是简单的，而真正重要的是这个查询分析了多少行数据。比如SELECTCOUNT(*)FROMlinksWHEREdomain=“mysql.com”;只返回一行，但却扫描了成千上万的记录（或者索引节点）。其他通常的杀手查询是GROUPBY查询和SORT查询----SELECTname,descrFROMtitlesORDERBYrankDESCLIMIT10----如果没有适当的索引，就会使用“filesort”，会有些问题。此外就是JOIN（关联）----关联是高代价的（当然是相对的），并且确实增加了为了产生结果集而使用的数据量----如果不得不关联10个表来组合出想要的结果，那么会比从一个表中得到同样的数据要慢很多。

检查结果集的生成实际需要的记录数。有时查询需要使用大量数据来产生结果集，是因为没有适当的索引----这是容易发生的。比如我们的ORDERBYrank查询就是这样----为rank列增加索引，会使这个查询仅使用10行数据来返回10行----恰恰是我们想要的。然而我们的COUNT(*)查询是不同的----即使在domain列上有索引，它仍然需要扫描很多行数据来得到结果集。这样的查询需要重新设计，而不是简单地调整----比如汇总表（summarytable）保存了每个域的link数量，就可以解决。

检查查询的次数。如果可以使用一个查询得到所需要的数据，那么就好于用多个查询得到同样的数据，前提是这一个查询不会因为与那些查询优化方式不同而需要分析更多行的数据。这里一个典型的例子是SELECT*FROMtblWHEREid=5执行了很多次，每次使用不同的常量----用类似IN(5,7,4,56)来替换是非常有效的。但也不要被这样的方法迷住。我曾经看到有人尝试用UNION（需要适当填充以使不同的字段数目及类型能够匹配）连接所有的查询----这不是个好主意。然而，如果可以减小查询的次数，而又不会增加应用程序架构的复杂性，那么是值得做的。