使用Ahoy gem查询Ahoy Event时出现PG语句超时错误

问题根因拆解 #

• 原查询超时的核心是过滤顺序踩了PG执行计划的坑：代码里先对全量Ran action事件做按周分组聚合，最后才匹配event_id的属性过滤条件，相当于需要扫描全表海量事件数据完成分组计算，很容易触发PG的语句超时保护机制自动中断查询。
• 之前尝试的find_in_batches方案不适用：这个方法的作用是批量遍历取出明细记录，本质还是需要把符合大筛选范围的全量数据拉取回来做处理，并没有从根源缩小扫描范围，自然无法解决聚合查询的超时问题。

可落地的优化方案 #

调整查询过滤顺序 #

把选择性最高、过滤范围最窄的条件放到查询最前面执行，尽可能缩小后续聚合操作需要处理的数据集大小，避免全表扫描。
对应调整后的查询代码：

Ahoy::Event
  # 先匹配精准的event_id属性，把目标数据集先缩小到单事件维度
  .where_props(event_id: current_event.id)
  .where_event('Ran action')
  .group_by_week(:time)
  .count

配套添加专用数据库索引 #

没有索引支撑的话，哪怕调整了查询顺序，PG还是会走全表扫描，需要给两个高频查询字段加专用索引，把查询的扫描成本从全表降到精准行匹配：

• 给存事件名称的name字段加普通B树索引，优化where_event的筛选效率
• 给props JSONB列中常用的event_id键加表达式索引，专门优化where_props的属性查询速度
  对应的数据库迁移代码：

class OptimizeAhoyEventQueryIndexes < ActiveRecord::Migration[7.0]
  def change
    add_index :ahoy_events, :name
    add_index :ahoy_events, "((props -> 'event_id'))", name: 'idx_ahoy_events_props_event_id'
  end
end

大表场景的兜底方案 #

如果单表数据量已经达到千万级以上，哪怕加了索引实时聚合还是有压力，可以把固定维度的按周聚合结果提前预计算，落到单独的统计表中，日常查询直接读取预存的统计值，不需要每次都扫原始事件表。
如果是临时需要跑一次单次查询、不适合改动线上结构的场景，可以临时放宽当前数据库会话的语句超时限制，查询执行完成后自动恢复默认阈值：

# 仅对当前会话生效，把超时阈值临时调整为10秒
ActiveRecord::Base.connection.execute("SET LOCAL statement_timeout = '10s'")
# 执行目标查询
Ahoy::Event.where_props(event_id: current_event.id).where_event('Ran action').group_by_week(:time).count

内容的提问来源于stack exchange，提问作者Marshall Đỗ