Rails sql延迟加载和自带缓存

color_lot_manuallies = color_lot.color_lot_manuallies
if color_lot_manuallies.size == 1
end

当有A has many B时，a.bs.size并不是检索出所有a.bs再求出size，而是直接用select count(*)来计算结果。这应该是延迟加载，有点类似named_scope,但是并不是named_scope,named_scope的结果类是ActiveRecord::NamedScope::Scope，但是A.bs.class的结果是Array，这部分看了下源码但是并没有看懂。
所以当我这样写的时候：

    color_lot_manuallies = color_lot.color_lot_manuallies
    if color_lot_manuallies.size == 1
    end
    color_lot.color_lot_manuallies.each do |i|
       puts i.id
    end

这样的话rails使用了延迟加载造成两个sql不同，所以后面。color_lot.color_lot_manuallies再次使用时，不会使用缓存的sql。
改成这样：

    color_lot_manuallies = color_lot.color_lot_manuallies.all
    if color_lot_manuallies.size == 1
    end
    color_lot.color_lot_manuallies.each do |i|
       puts i.id
    end

加一个all，color_lot.color_lot_manuallies.all，这样的话，后面再次调用时，会使用rails的sql缓存。

#PurchaseOrder 
  has_one :purchase_order_marketing, :dependent => :destroy
  has_many :purchase_invoices, :dependent => :destroy,:through => :purchase_order_marketing
#PurchaseOrderMarketing
  has_many :purchase_invoices,:dependent => :destroy

PurchaseOrder.first.purchase_invoices.all(:select => 'purchase_invoices.id')

一条sql就完成了，真强大。

  #article
def sizes
    sizes = []
    art = self
    sf = art.article_secondary_feature
    size_group = SizeGroup.find_by_id(sf.size_groupid) if sf
    sizes = size_group.sizes if size_group
    return sizes
  end

ArticleMarketing.first.article.sizes.all(:select => 'id')

 
find和find_by_id

params[:root].classify.constantize.find_by_id(params[:id])
params[:root].classify.constantize.find(params[:id])

find_by_id的SQL多了一行limit 1，对于sql语句而言，有一点性能上的提高。不过有时候我们需要find来捕捉异常。如果能用find_by_id最好了。
都改成find_by_id

这样都有缓存了。rails的自带的缓存是很脆弱的，B.find_by_id(a.id)方法变成a.b时，这个缓存就不会用上。同样前面的例子里改成

    color_lot_manuallies = color_lot.color_lot_manuallies.all
    ColorLotManually.find_all_by_color_lot_id(color_lot.id)

rails自带的缓存也不会用上。
关于||=缓存，参考
http://fuliang.iteye.com/blog/827321
http://www.iteye.com/topic/810957
但是有一点，||=不会自动清除或者更新，所以使用的时候还是要注意点，可能会引起取值错误，而且不会报错。

class PortOfDischage < ActiveRecord::Base
  def _name
    @_name ||= self.city
  end
end

Reloading...
=> true
>> p=PortOfDischage.first
  SQL (0.2ms)   SET SQL_AUTO_IS_NULL=0
  PortOfDischage Load (21.2ms)   SELECT * FROM `port_of_dischages` LIMIT 1
  PortOfDischage Columns (1.7ms)   SHOW FIELDS FROM `port_of_dischages`
+----+------------+-----------------+---------+---------+--------------------------------+--------------------------------+
| id | ap_list_id | ap_marketing_id | city    | country | created_at                     | updated_at                     |
+----+------------+-----------------+---------+---------+--------------------------------+--------------------------------+
| 1  | 2          | 2               | Piraeus | Greece  | Thu Oct 07 07:10:21 +0800 2010 | Thu Oct 07 07:10:21 +0800 2010 |
+----+------------+-----------------+---------+---------+--------------------------------+--------------------------------+
1 row in set
>> p._name
=> "Piraeus"
>> p.update_attribute(:city,'p')
  SQL (0.2ms)   BEGIN
  ApMarketing Columns (43.0ms)   SHOW FIELDS FROM `ap_marketings`
  ApMarketing Load (18.6ms)   SELECT * FROM `ap_marketings` WHERE (`ap_marketings`.`id` = 2) 
  PortOfDischage Update (45.5ms)   UPDATE `port_of_dischages` SET `updated_at` = '2010-12-30 13:08:47', `city` = 'p' WHERE `id` = 1
  SQL (55.5ms)   COMMIT
=> true
>> p._name
=> "Piraeus"
>> p.city
=> "p"
>> p.reload
  PortOfDischage Load (0.7ms)   SELECT * FROM `port_of_dischages` WHERE (`port_of_dischages`.`id` = 1) 
+----+------------+-----------------+------+---------+--------------------------------+--------------------------------+
| id | ap_list_id | ap_marketing_id | city | country | created_at                     | updated_at                     |
+----+------------+-----------------+------+---------+--------------------------------+--------------------------------+
| 1  | 2          | 2               | p    | Greece  | Thu Oct 07 07:10:21 +0800 2010 | Thu Dec 30 13:08:47 +0800 2010 |
+----+------------+-----------------+------+---------+--------------------------------+--------------------------------+
1 row in set
>> p._name
=> "Piraeus"

ActiveRecord的has_many关联和scope很相似，都用了delegation，rails 2.3.x中返回的是namedscopes或associations。
虽然返回的是array，但是在对返回的associations或namedscopes调用方法时候，会根据不同的方法，delegate到不同的对象。
调用:scopes, :with_scope, :scoped_methods等时继续返回scope
调用除了[nil? send object_id class extend find size count sum average maximum minimum paginate first last empty? any? respond_to?]中的方法时，先调用.all方法进行db操作。
即：
user.posts.each{...} == user.posts.all.each{...}
Rails3就更变态了，到处是lazy loading.
where
having
select
group
order
limit
offset
joins
includes (:include)
lock
readonly
from
这些方法都仍然返回一个Relation对象。直到调用map/each等方法才真正的进行数据库操作。



这样的日志是mysql的缓存吧，和rails一点关系没有。
无论find还是find by id都进行了一次db操作。而这样的主键查询有没有limit 1貌似没有差别吧。
find和find by id的最大区别就是抛不抛异常的区别。还有就是find by 会调用method_missing，很多人说这东西慢...
像这样简单的查询，用cache money或其他缓存插件都可以避免hit db的。

这个是rails的缓存。mysql的缓存是另外一回事，你搞混了。
加limit 1还是有一点点效果的，你可以在mysql下做下测试。
我标题里已经写了，rails自带缓存。当然，如果用memcache或者其他的插件，这个应该是可以避免hit db的。不知道有没有办法把rails的自带缓存禁止掉。

rails3还没怎么玩。恩，delegate，恩，有时间在看看。

确实搞混了，这个是rails的QueryCache打的日志～～
这个缓存是action级别的，一个action之内的相同查询不会再去数据库取新的（如果当前action没有更新这条记录）。但弱的很，不过不需要手动设置什么，很方便的。也有一些隐藏的危险，比如：

p User.first(:order => "RAND()")
p User.first(:order => "RAND()")

这样两次结果是相同的，如果开启了QueryCache。

这个效果还真没看出来，可能数据太少了。

User.uncached do
  p User.first(:order => "RAND()").id
  p User.first(:order => "RAND()").id
end

（占位）
很邪恶。。这个order by rand貌似mysql都不会缓存吧。。

这些方法都仍然返回一个Relation对象。直到调用map/each等方法才真正的进行数据库操作。 

是对数据进行操作系吧。不然执行的不会那么慢，不知道你说的是3还是2+

我理解的mysql缓存是在select和where中间的那个字段或值，不知道正不正确，求解

http://coolshell.cn/articles/1846.html#more-1846

都是需要驱动的：
返回的是namedscopes或associations，因为有时候我们的目的并非是查询，还可能会创建或其他操作，比如current_user.posts.new,这个时候current_user.posts就不能直接查询返回数组了。

find 和 find_by也是根据需要场景来决定用谁。个人觉得比较他们的性能并没有意义。

find_by == find(:first)，是find的特别版，find是不是抛异常和它返回是数组还是别的，要看find的第一个参数是什么。

如果你需要判断一个记录是否存在并返回它，就用find_by，如果仅仅是批量查询就用find

http://coolshell.cn/articles/1846.html#more-1846
比较性能，多数情况下确实没太大意义。。
不过因为项目里面有类似于exist?(id)，然后find(id),如此多此一举。
而且也只有这个表记录在20多万，数据量稍微多点，查询相当频繁，基本上每个action会查几十次。就这种情况下做了下修改，都改成了find_by.