英文版 更有趣些
主要是来解决 includes 和 counter_cache 无法解决的一些 n+1 查询，比如
SELECT "posts".* FROM "posts";
SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 1 AND "comments"."status" = 'approved'
SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 2 AND "comments"."status" = 'approved'
SELECT COUNT(*) FROM "comments" WHERE "comments"."post_id" = 3 AND "comments"."status" = 'approved'
=>
SELECT "posts".* FROM "posts";
SELECT COUNT(*) AS count_all, post_id AS post_id FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3) AND "comments"."status" = 'approved' GROUP BY post_id;
或者是
SELECT "posts".* FROM "posts";
SELECT AVG("comments"."rating") AS avg_id FROM "comments" WHERE "comments"."post_id" = 1;
SELECT AVG("comments"."rating") AS avg_id FROM "comments" WHERE "comments"."post_id" = 2;
SELECT AVG("comments"."rating") AS avg_id FROM "comments" WHERE "comments"."post_id" = 3;
=>
SELECT "posts".* FROM "posts";
SELECT AVG("comments"."rating") AS average_comments_rating, post_id AS post_id FROM "comments" WHERE "comments"."post_id" IN (1, 2, 3) GROUP BY post_id;
使用起来会很简单
class Post < ActiveRecord::Base
has_many :comments
define_eager_group :comments_average_rating, :comments, :average, :rating
define_eager_group :approved_comments_count, :comments, :count, :*, -> { approved }
end
class Comment < ActiveRecord::Base
belongs_to :post
scope :approved, -> { where(status: 'approved') }
end
用 define_eager_group 来定义 aggregate sql functions，然后就可以用 eager_group 来查询
posts = Post.all.eager_group(:comments_average_rating, :approved_comments_count)
posts.each do |post|
post.comments_average_rating
post.approved_comments_count
end
做了简单的性能测试，可以快非常多，我的例子是 10 倍。
提供另外两种方案：
Counter Cache With Condition
counter cache with condition 的思路是继续在 post 表里加字段，记录带条件的聚合查询结果：
belongs_to :folder
counter_cache_with_conditions :folder, :messages_count, {}
counter_cache_with_conditions :folder, :unread_messages_count, :unread => true
counter_cache_with_conditions :folder, :unread_messages_count, [:read, :source], lambda{|read, source| read == false && source == 'message'}
counter_cache_with_conditions :folder, :published_events_count, [:published_at], lambda{|published_at| published_at != nil }
项目地址，似乎不维护了：https://github.com/skojin/counter_cache_with_conditions
物化视图
SQL 里，group 是在做 aggregation，join 在做 composition。通过这两个，我们可以得到任意结果。
原本 comments_count 和 approved_comments_count 不在 post 表里，但我们可以通过 aggregation 和 composition 让他们在一起。
SELECT posts.id AS post_id, COUNT(comments.id) AS comments_count, COUNT(comments.apporved = 1) AS approved_comments_count
FROM posts
INNER JOIN comments ON posts.id = comments.post_id
GROUP BY posts.id
LIMIT 5;
+---------+----------------+-------------------------+
| post_id | comments_count | approved_comments_count |
+---------+----------------+-------------------------+
| 56621 | 1 | 1 |
| 56626 | 1 | 1 |
| 56627 | 1 | 1 |
| 56628 | 1 | 1 |
| 56632 | 1 | 1 |
+---------+----------------+-------------------------+
有了这个视图，我们可以用 join 把所需的数据组合起来，变成这个样子：
+---------+-------+------+----------------+-------------------------+
| post_id | title | body | comments_count | approved_comments_count |
+---------+-------+------+----------------+-------------------------+
| 56621 | title | body | 1 | 1 |
| 56626 | title | body | 1 | 1 |
| 56627 | title | body | 1 | 1 |
| 56628 | title | body | 1 | 1 |
| 56632 | title | body | 1 | 1 |
+---------+-------+------+----------------+-------------------------+
看到这里，大家一定觉得我在扯淡，又 join 又视图的，性能怎么能变快？
是的，视图其实和正常的 SQL 查询一样，我们上面的过程其实等价于先 GROUP 一次，然后再 JOIN 一次。所以结果会慢的惊人。更重要的是视图不能利用索引。
引入物化视图：
CREATE MATERIALIZED VIEW post_agg_mv AS
SELECT posts.id AS post_id, COUNT(comments.id) AS comments_count, COUNT(comments.apporved = 1) AS approved_comments_count
FROM posts
INNER JOIN comments ON posts.id = comments.post_id
GROUP BY posts.id
ORDER BY posts.id ASC
post_agg_mv 是一个真实存在的表，可以在上面加索引。同步的话，可以使用REFRESH MATERIALIZED VIEW post_agg_mv，按照你数据变更的频繁程度，自己选择是实时、延迟、还是定时刷新；是在 callback 还是 trigger。反正最终数据是一致的。
+---------+----------------+-------------------------+
| post_id | comments_count | approved_comments_count |
+---------+----------------+-------------------------+
| 56621 | 1 | 1 |
| 56626 | 1 | 1 |
| 56627 | 1 | 1 |
| 56628 | 1 | 1 |
| 56632 | 1 | 1 |
+---------+----------------+-------------------------+
然后，组合的时候也不需要用 JOIN，include 仍然有效：
posts = Post.include(:post_agg_mv).all
posts.each do |post|
post.comments_average_rating #需要delegate一下
post.approved_comments_count
end
物化视图的作用不止用于聚合，同样可以用于组合，比如 catalog、SPU、SKU 这种嵌套很深的表结构，有时候查询需要 JOIN 几个表，在查询的时候直接使用物化视图来查结果快很多，有写入的时候刷新一下就保证数据同步。
- MySQL 没有物化视图，不过也可以自己实现。
- Postgresql: http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views
- counter_cache_with_conditions，我之前也考虑过加字段手动维护，但是一旦条件变复杂了，数据很容易发生偏差，另外 counter_cache_with_conditions 只能支持 COUNT，其它聚合函数就无能为力了。
- view 也是不错的选择，但是结果会变慢，而且在 rails 中维护 db view 是非常麻烦的。materialized view 就更不合适了，需要定时刷新，数据的实时性被破坏了。
- 同意
关于定时刷新问题其实没有想象那么严重，上面提到
按照你数据变更的频繁程度，自己选择是实时、延迟、还是定时刷新。实际项目中，其实写入没有那么频繁，比如像 RubyChina 这样的应用，我只要保证有回帖和发帖实时刷新就可以，性能完全不是问题。当然，数据量大到一定程度的话，实时刷新代价太大，可以考虑延迟和定时刷新，这样只会有部分数据发生微小偏差，但可以保证最终数据的一致性。还是实际中使用的问题，您的需求显然是为 eager group 专门设计的，但我只要稍微改变一点需求，eager group 立马变得不可用，而且这个改动还是非常合理的：按照 approved_comments_count 倒序分页。Materialized View 方案就完全可以解决：
Materialized View + JOIN 方案：
posts = Post.joins(:post_agg_mv).order("approved_comments_count DESC").limit(10).all
posts.each do |post|
post.comments_average_rating #需要delegate一下
post.approved_comments_count
end
Materialized View + include 方案：
// 注：post_agg_mv.approved_comments_count 上面上可以加索引的
posts_mv = PostAggMv.include(:post).order("approved_comments_count DESC").limit(10).all
posts_mv.each do |post_mv|
post = post_mv.post
post.comments_average_rating #需要delegate一下
post.approved_comments_count
end
@hooopo 这个需求的确是还不能支持，但是也不难，就像 includes + where/order 可以转成 JOIN，eager_group + where/order 也可以通过 JOIN 来完成。
@hooopo 是的，不过如果实时性要求不高的话，与其用 materialized view，我更倾向用 redis 的 sorted set 来实现排序。
有篇文章介绍在 rails 中如何使用 ActiveRecord + PostgreSQL Materialized Views
感觉这个 gem 不错，可以制定 refresh triggers，指定更新某一行的 materialized_views materialized_views
试了一下，polymorphic 情况下的 has_many through 不行。
class Organization
has_many :dynamic_field_adapters, as: :attached
has_many :dynamic_fields, through: :dynamic_field_adapters
define_eager_group :fields_count, :dynamic_fields, :count, :*
end
Organization.limit(2).eager_group(:fields_count).first.fields_count
# => nil
#13 楼 @yakjuly 我应该已经在 v0.2.0 加了对 has_many :through 的支持， https://github.com/xinminlabs/eager_group/blob/master/spec/integration/eager_group_spec.rb
