Rails中处理has_many关联查询时避免N+1问题的有效方法

核心问题根源 #

当前写法触发N+1的本质是：在视图循环中反复给关联追加where过滤条件，哪怕提前用includes加载了全量关联，Rails也会把带额外查询条件的关联调用判定为新的数据库请求，无法复用内存中已经加载的关联数据。

最优实现方式（Rails 原生支持，无额外依赖） #

第一步：在Movie模型中定义带固定过滤逻辑的专属关联 #

不要在视图层写零散的查询条件，把对应过滤规则和关联绑定，Rails会自动优化这类关联的预加载逻辑：

# app/models/movie.rb
class Movie < ApplicationRecord
  # 原有基础关联
  has_many :media_types

  # 定义三个带过滤条件的自定义关联，和原视图判断逻辑完全对齐
  # 所有可正常访问的有效媒体类型（URL未失效）
  has_many :active_media_types, -> { where(url_broken: false) }, class_name: 'MediaType'
  # 有效流媒体资源
  has_many :streams, -> { where(dvd: false, url_broken: false) }, class_name: 'MediaType'
  # 有效DVD资源
  has_many :dvds, -> { where(dvd: true, url_broken: false) }, class_name: 'MediaType'
end

第二步：查询时一次性预加载所有需要的关联 #

不需要自定义特殊的连表查询方法，直接用Rails自带的预加载能力就可以实现“一次性获取所有关联数据”的效果，全流程仅触发2条SQL查询：

# 查询所有电影，同时一次性把上述3个关联的有效数据匹配挂到对应电影对象上
@movies = Movie.all.includes(:active_media_types, :streams, :dvds)

这一步的执行逻辑：第一条SQL拉取所有Movie记录，第二条SQL拉取所有和这些Movie绑定、符合三个关联过滤条件的MediaType记录，按movie_id分组做内存挂载，后续循环过程中不会再触发任何逐对象的数据库查询。

第三步：简化视图逻辑，直接调用预加载好的关联 #

完全不需要你设想的循环拆分传入streams、dvds参数的写法，预加载后的关联可以直接在movie_item局部视图中调用：

<h1><%= movie.title %></h1>

<% if movie.active_media_types.blank? %>
  No media types exist
<% else %>
  <h2>Streams</h2>
  <% movie.streams.each do |media_type| %>
    * <%= media_type.name %>
  <% end %>

  <h2>Dvd's</h2>
  <% movie.dvds.each do |media_type| %>
    * <%= media_type.name %>
  <% end %>
<% end %>

替代方案（可实现但不推荐） #

如果不想在模型里新增关联，也可以通过预加载全量media_types后在内存做过滤，同样能避免N+1，但会多加载冗余的无效媒体类型数据：

• 查询时预加载全量关联：

  @movies = Movie.all.includes(:media_types)
  

• 视图里用Ruby内存过滤代替数据库where查询：

  <% active_media = movie.media_types.select { |mt| !mt.url_broken } %>
  <% if active_media.blank? %>
    No media types exist
  <% else %>
    <% streams = active_media.select { |mt| !mt.dvd } %>
    <% dvds = active_media.select { |mt| mt.dvd } %>
    # 后续循环渲染streams、dvds列表即可
  <% end %>
  

额外提醒 #

• 原代码里写的includes(:movie_item)是无效代码，movie_item是局部视图的文件名，不是Movie模型的关联关系，这个includes不会起到任何预加载作用。
• 模型层定义带条件关联的方式，比手动内存过滤的方案更高效，因为预加载SQL会直接带上过滤条件，不会把url_broken = true的无效媒体类型数据从数据库拉回来。

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