嵌套关联记录缓存优化方案咨询

模型关联关系 #

class Post < AbstractModel
  belongs_to :user
  has_many :comments
  has_many :votes
end

class Comment < AbstractModel
  belongs_to :post
  belongs_to :user
  has_many :votes
end

class Vote < AbstractModel
  belongs_to :user
  belongs_to :comment
  belongs_to :post
end

class User < AbstractModel
  has_many :comments
  has_many :posts
  has_many :votes
end

实际关联逻辑更复杂，但核心关联如上。当前posts、comments、users表数据量庞大，展示Post页面时速度极慢。已实现预加载（eager loading），但在有数百万条记录的遗留系统中，嵌套记录的数据库加载速度依旧不理想。

在Post模板里，加载附带votes和users的comments是最耗时的环节，即便已经在各处用includes预加载依赖记录。

核心需求：有没有办法缓存数据库查询，仅在底层依赖记录变更时让缓存失效？

补充说明：

• 应用支持多语言翻译，无法直接缓存HTML
• 曾考虑在Post模型中新增序列化列comments_cache，在评论发布或投票时更新该列，存储comments、users和votes的序列化哈希：

class Post < AbstractModel
  serialize :comments_cache
end

• 使用MySQL数据库，预加载和查询缓存速度可能是影响因素
• 顾虑：序列化可能导致数据损坏（但该列不是数据源，仅从独立记录序列化而来）、Ruby序列化/反序列化的性能，且违反第一范式并非理想方案

1. 细粒度依赖触发式查询缓存 #

用Redis或Memcached实现精准缓存，核心是给关联资源绑定缓存键，仅在数据变更时失效对应缓存：

• 为每个Post的评论集合生成唯一缓存键，比如post_comments_with_assocs:{post_id}
• 缓存内容用JSON序列化预加载了user和votes的评论集合（避免Ruby原生序列化的兼容性问题）
• 触发缓存失效的时机：
  • Post新增/删除评论时，直接失效对应Post的评论缓存键
  • Comment内容、关联User信息变更，或该Comment的votes数量变化时，找到所属Post并失效其缓存键
  • User信息变更时，异步批量失效该User所有评论所属Post的缓存键（避免同步请求阻塞）

这种方式不污染数据库结构，缓存失效精准，比序列化列更灵活。

2. MySQL层面优化预加载 #

先排查预加载SQL的性能瓶颈：

• 用select指定模板所需字段，避免查询冗余数据，减少传输量
• 给关联字段建立联合索引：比如给comments表建(post_id, user_id)联合索引，votes表建(comment_id, user_id)联合索引，加速关联查询
• 若数据量过大，考虑按Post创建时间或用户ID拆分comments表，降低单表查询压力

3. 物化视图替代序列化列 #

如果不想用缓存，可在MySQL中创建物化视图预计算聚合数据：

• 创建物化视图，包含Post ID、评论内容、用户信息、投票数等模板所需字段
• 通过触发器或业务代码，在评论、投票、用户信息变更时更新对应物化视图数据
• 查询时直接从物化视图获取数据，避免嵌套关联查询
• 注意：MySQL原生不支持自动刷新物化视图，需自行实现刷新逻辑，但比序列化列更符合数据库范式

4. 序列化列方案的优化（若坚持使用） #

如果还是想尝试序列化列，可做以下优化降低风险：

• 用JSON序列化替代Ruby默认的Marshal，即serialize :comments_cache, JSON，提升可读性与反序列化性能，避免版本兼容问题
• 仅序列化模板需要的字段（比如评论的id/content、用户的username/avatar_url、投票的count），减少序列化数据体积
• 用异步任务处理缓存列的更新，避免阻塞请求

内容的提问来源于stack exchange，提问作者nimmolo