Rails PostgreSQL多对多关联计数查询性能问题咨询

前两种实现方案的问题 #

• 方案1（includes预加载）性能差的核心原因是过度加载：includes的设计目标是预加载关联模型的全量数据，供后续访问关联字段使用，会把所有匹配的BusinessModel全字段数据拉回应用服务器，再由ActiveRecord实例化成Ruby对象。你提到BusinessModel字段多、关联表数据量极大，哪怕SQL执行耗时短，海量对象的初始化、内存占用开销会非常高。且你调用size时，因为关联已经加载到内存，size不会触发数据库count查询，直接计算内存中关联数组的长度——相当于你为了判断「有没有关联」，把所有关联的完整业务数据都加载了，资源浪费极其严重。
• 方案2（无预加载逐次查询）小数据量下速度快，本质是因为你分页只取50条记录，触发的50条COUNT(*)单查询本身开销极低，但这是典型的N+1反模式：一旦分页条数上调、接口并发升高，大量重复的count查询会快速占满数据库连接，没有任何生产环境可用性。

第三种方案的评估与优化 #

你选择的NOT EXISTS方案方向完全正确，是判断关联存在性的最优实践：

PostgreSQL执行EXISTS子查询时，只要匹配到第一条符合条件的关联记录就会立刻终止扫描，既不需要统计全量关联总数，也不需要加载关联表的任何业务字段，性能远高于全量预加载、count查询，且仅需执行单条SQL，没有N+1风险。

不过你当前的写法有两个细节问题需要修正：

1. 语法错误：:description后误写了点号，应该为逗号；另外要确认多对多关联表的实际表名（Rails默认HABTM关联表命名是两个模型名按字母排序拼接，即business_models_master_models），替换你写的占位表名many避免SQL报错；同时原生SQL片段需要用Arel.sql包裹，避免Rails的安全校验报错。
2. 调用逻辑错误：removable是你挂载在MasterModel查询结果上的虚拟属性，直接在MasterModel实例上调用即可，不需要通过business_models关联调用。

修正后的代码示例：

MasterModel.select(
  :id,
  :name,
  :description,
  Arel.sql(
    'NOT EXISTS (
      SELECT 1
      FROM business_models_master_models
      WHERE business_models_master_models.master_id = master_models.id
    ) AS removable'
  )
).limit(50).offset(0).each do |master|
  # 直接读取虚拟属性判断是否可删除
  master.removable # 返回true/false
end

如果不想写原生SQL，也可以用Rails内置的左连接写法实现同等效果，语义更贴合Rails开发规范：

MasterModel.left_joins(:business_models)
  .select(
    :id,
    :name,
    :description,
    Arel.sql('COUNT(business_models.id) = 0 AS removable')
  )
  .group(:id)
  .limit(50)
  .offset(0)

额外性能提示：请确保多对多关联表已经添加了(master_id, business_model_id)的联合索引，可以进一步把EXISTS查询的耗时降到毫秒级。

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