前言

关于数据库查询，让我们来看一看那些让你的程序停滞不前的罪魁祸首。

我还记得我第一次看到rails的ActiveRecord，那是一次启发。那是2005年的时候，当时我在给一个PHP程序写SQL语句。突然间，写数据库从单调繁杂的零星工作变得简单且有趣了。

...然后我就开始关注到性能(performance)的问题。

ActiveRecord它本身并不慢。我停止把注意力花在那些实际正在运行的查询上。结果是，当数据量变得庞大后，在rails的增删查改操作中一些最符合语言习惯的数据库查询就十分低效。

这篇文章我们将讨论这其中的三个罪魁祸首。但首先，让我们先聊聊怎么知道你的数据库查询是否高效。

测量性能

如果你数据量足够小的话每个数据库查询都是高效的。所以为了真正地感知效率，我们需要以一个生产级别的数据库为基准。在我们的示例中，我们将使用一个有大约22000条记录的叫做faults的表。

我们会用到postgres。在postgres中，衡量性能的方法是使用explain。比如：

# explain (analyze) select * from faults where id = 1;
                                     QUERY PLAN
----------------------------------------------------------------------------------------
 Index Scan using faults_pkey on faults  (cost=0.29..8.30 rows=1 width=1855) (actual 
time=0.556..0.556 rows=0 loops=1)
   Index Cond: (id = 1)
 Total runtime: 0.626 ms

这显示出了执行这次查询的预计花费 (cost=0.29..8.30 rows=1 width=1855) 和执行的实际时间(actual time=0.556..0.556 rows=0 loops=1)。

如果你想要一个更易读的格式，你可以让postgres以YAML文件打印出来。

# explain (analyze, format yaml) select * from faults where id = 1;
              QUERY PLAN
--------------------------------------
 - Plan:                             +
     Node...