Ruby on Rails使用where按日期过滤Posts时引发大量数据库查询求助

• 你猜测的时间精度问题完全成立：Rails的查询缓存完全匹配SQL语句和绑定参数，你在where中直接传入Time.now.in_time_zone，每次执行查询时时间值都会发生变化，导致缓存完全无法命中，每次请求都会生成新的SQL发起数据库调用。而去掉where逻辑后，查询的参数仅为固定的user_id和organization_id，缓存可以正常命中，因此不会出现频繁查询的问题。
• where语句存在语法隐患：你写的end_date IS?缺少空格，实际生成SQL时会拼接为end_date ISNULL（当传入nil时），虽然部分数据库能兼容，但不符合标准SQL规范，可能导致索引失效、查询变慢。
• 实例变量缓存作用域有限：你用@valid_posts ||=做的缓存仅在当前PostSetFilter实例的生命周期内生效，而你的控制器每次收到请求都会新建一个PostSetFilter实例，跨请求完全无法复用缓存，高并发下会产生大量重复查询。
• 额外小问题：Rails模型类名为单数形式，代码中的Posts.for_user如果不是笔误需要修正为Post.for_user，否则会触发常量不存在报错。

1. 修复查询写法，避免参数动态变化 #

优先使用更符合Rails规范的查询写法，同时把nil条件固定写死，减少可变参数：

# 修正后的where写法，避免语法问题
@valid_posts ||= Post.for_user(user)
                     .where("end_date > ? OR end_date IS NULL", Time.current.in_time_zone)
                     .pluck(:post_set_id)

如果业务允许分钟级的时间误差，可以对时间做取整处理，保证一分钟内的查询参数完全一致，命中Rails内置的查询缓存：

time_threshold = Time.current.in_time_zone.beginning_of_minute
@valid_posts ||= Post.for_user(user)
                     .where("end_date > ? OR end_date IS NULL", time_threshold)
                     .pluck(:post_set_id)

2. 增加跨请求低级别缓存 #

针对每次请求新建实例导致缓存失效的问题，用Rails低级别缓存存储查询结果，设置合理的过期时间，大幅降低数据库调用量：

@valid_posts ||= Rails.cache.fetch([:valid_post_set_ids, user.id, Time.current.to_i / 60], expires_in: 1.minute) do
  Post.for_user(user)
      .where("end_date > ? OR end_date IS NULL", Time.current.in_time_zone)
      .pluck(:post_set_id)
end

上面的缓存key按分钟维度生成，同一用户一分钟内的所有请求都会直接读缓存，无需查询数据库。

3. 新增覆盖索引优化查询速度 #

索引优化虽然不能直接解决查询次数多的问题，但可以大幅降低单次查询的耗时和内存占用，建议新增联合覆盖索引，所有查询字段都包含在索引中，数据库无需回表查询：

# 在迁移文件中添加索引
add_index :posts, [:user_id, :organization_id, :end_date, :post_set_id], name: "index_posts_on_user_org_end_date_post_set_id"

4. 接口层增加HTTP缓存（可选） #

如果这个接口的实时性要求不高，可以在控制器层面加HTTP缓存，对相同请求直接返回304响应，完全不用走到业务逻辑：

def post_ids
  post_pools = PostSetFilter.new(user: user)
  fresh_when etag: post_pools, last_modified: Post.where(user_id: user.id, organization_id: user.organization_id).maximum(:updated_at)
  render json: {PostPools: post_pools}
end

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