Rails 3中订单查询的效率
所以，我想知道下面哪一个更有效。实际上，最好的答案是，我将来如何才能弄清楚这一点。
这两个查询是：
# id integer
# created_at datetime
# collection_id integer
# updated_at datetime
class Post < ActiveRecord::Base
belongs_to :collection
end
Post.where(:collection_id => collection_id).order(:updated_at).lastvs
Post.where(:collection_id => collection_id).order("updated_at DESC").first所以，2个部分的问题：
1)这些语句中哪一个更有效？(除非我有拼写错误，否则它们应该是等效的)
2)我怎么能自己回答这个问题？
我假设没有索引。我还想知道答案是否会根据查询的by collect_id部分的结果集的预期大小而变化。
回答 2
Stack Overflow用户
发布于 2011-10-25 07:28:09
至少在Rails 3.1中，您的两个查询实际上将在数据库上运行相同的查询。Rails足够聪明，知道在查询上调用.last应该颠倒顺序，将其限制为单个请求。因此，下面这行代码实际上只是将ORDER BY updated_at DESC LIMIT 1添加到查询的末尾。换句话说，这一行不是返回数据库中的所有记录，而是为每条记录创建ActiveRecord对象，然后返回最后一条记录，这将大大降低效率。
Post.where(:collection_id => collection_id).order(:updated_at).lastStack Overflow用户
发布于 2011-10-25 07:18:58
如果您观察控制台，您将看到(1)实际正在执行的是什么查询，以及(2)执行所用的时间。这将是跟踪效率的基本方法。
在生产环境中，也有像NewRelic RPM这样的工具可以为您提供执行查询的速度/时间的警告/分析。我认为免费版本将进行效率分析，但只保留应用程序运行时间的前30分钟的记录。
一般来说(但不是严格地说)，发送的查询数量越少越好，部分原因是它涉及Rails和DB之间的往返次数更少。
如果您想要一些免费的东西，并且可能更具可重复性，那么您可以添加一些性能测试，在这些测试中，您可以一遍又一遍地运行查询，在每次运行时对它们进行计时，只需确保查询/控制器操作的运行时间少于您选择的某个基准，或者多次执行的平均时间低于某个阈值。
这个方法还可以用来监视在你的应用程序中最经常被点击的操作，如果它们花费的时间比预期的要长，就会失败。测试将只涵盖模拟环境，当然，be可以用作关键操作是否完全与预期性能脱节的一般指示。
https://stackoverflow.com/questions/7883007
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号