检索数据库数据的 finder 方法的性能答案

【问题标题】：Performance on finder methods to retrieve database data检索数据库数据的 finder 方法的性能
【发布时间】：2011-09-16 18:05:18
【问题描述】：

我正在使用 Ruby on Rails 3.0.7，我想知道使用 User.all 方法的优点和缺点（与性能有关），然后对每个请求的结果执行查找器方法而不是使用User.find(<id>) 单独检索每条记录。

我问这个是因为在我的 view 文件中我有这样的东西：

accounts.each { |account|
  puts account.user.name
}

更新

例如，Stackoverflow 网站如何处理有关查找器方法的标签？

【问题讨论】：

【解决方案1】：

除非您确定数据集非常小，最多只有几十条记录，否则不要获取任何东西的all。获取所有用户会导致灾难，因为此操作的内存使用量将随着系统上的用户数量线性增加。

您必须在大多数情况下检索子集时使用find 或where 方法，除非您可以绝对确定所涉及的记录数量是微不足道的。

我什至提倡使用select_values 或select_rows，当您只需要一点点数据而没有模型开销时，这对于大型表格列表很有效。

请记住，当您加载模型时，默认情况下会加载与其关联的所有内容。对于用户来说，这可能包括他们的扩展传记、他们的地址、他们最喜欢的颜色、他们的电子邮件、他们的密码，而您在扔掉那个对象之前只使用他们的名字。如果性能受到关注，请仅获取您需要的内容。

在控制器中包含以下内容几乎总是错误的：

@users = Users.all

您需要做的是分页，否则随着更多用户在您的系统上注册，该页面将逐渐变慢。在某些时候，页面将永远无法正确呈现，因为它会首先超时。

【讨论】：

@tadman - 1.000 可能微不足道吗？ 10.000可以是微不足道的吗？ 100.000 可以是微不足道的吗？只是想知道...
Trivial 通常意味着“几十个”，但对于只有几个简单字段的真正轻量级记录，您可能能够逃脱数百个。较重的物体会很快加起来。
@tadman - 那么，在“每个”块中使用 1.000 个“User.find()”方法是错误的吗？
@tadman - 我还用一点“子问题”更新了这个问题。
设计高效应用程序的想法是尝试尽可能减少查询次数，同时获取所需的最少信息量。在某些时候，进一步优化并不重要，对于不注重性能的轻负载应用程序来说，这可以非常轻松。 User.find 的 1,000 个实例是一个错误。相反，您应该使用User.where(:id => ids)，其中ids 是您想要的ID 列表。批量获取所需的大小，因为如果重复执行，创建和执行语句的时间确实会加起来。