Laravel Rebing GraphQL分页比返回全量数据慢4-5倍的问题排查

核心原因 #

• 分页查询（不管是paginate还是simplePaginate）必须额外执行总数统计查询，你的查询里既有GROUP BY聚合逻辑，又加了AND "joining_total_score"."total_filtered_score" > 0的过滤条件，数据库得先完成全量聚合计算才能统计符合条件的总数，这就是耗时的核心——XDebug显示的36秒总数计算耗时就是明证。
• 全量查询不需要单独统计总数，直接返回聚合后的结果，所以耗时只有15秒；但分页时的总数统计，数据库没法高效利用索引完成聚合+过滤的统计，只能全量扫描计算，自然慢很多。

解决办法 #

1. 针对性优化索引 #

• 给joining_total_score表的total_filtered_score字段，搭配聚合查询用到的分组字段创建复合索引。比如分组字段是user_id，就执行：

  CREATE INDEX idx_total_score_group ON joining_total_score (total_filtered_score, user_id);
  

• 同时确保关联查询里用到的其他表字段也有合适的索引，减少关联时的全表扫描。

2. 改用游标分页（跳过总数统计） #

• 如果前端不需要总页数，直接用cursorPaginate替代普通分页。游标分页不需要计算总记录数，只靠上一页最后一条记录的游标来获取下一页数据，彻底避开总数统计的耗时。
• 在Rebing GraphQL的resolver里，把分页逻辑从->paginate()改成->cursorPaginate()，同时调整GraphQL的分页参数为after/first这类游标相关参数。

3. 预计算聚合结果 #

• 把total_filtered_score的聚合计算逻辑，通过Laravel的定时任务（Artisan命令+调度）提前算好，存到单独的统计表里。比如每天凌晨统计一次符合total_filtered_score > 0的聚合数据，分页时直接查这个预计算表，不用实时聚合。
• 如果对实时性要求高，就用数据库触发器，原表数据变更时自动更新预计算表的结果。

4. 手动编写高效的总数统计SQL #

• 别用Laravel自动生成的总数统计SQL，自己写更高效的逻辑：先过滤total_filtered_score > 0的记录，再做分组统计总数，而不是先分组再过滤。示例SQL：

  SELECT COUNT(DISTINCT group_field) FROM joining_total_score WHERE total_filtered_score > 0 [其他关联条件]
  

• 在Laravel里用DB::select()执行这段统计SQL，然后把结果传入分页构造器，替换自动的总数统计：

  $total = DB::select('SELECT COUNT(DISTINCT user_id) FROM ...')[0]->count;
  $data = $query->where('joining_total_score.total_filtered_score', '>', 0)->paginate(15, ['*'], 'page', $page)->setTotal($total);
  

5. 业务允许的话，先分页再过滤 #

• 如果业务能接受，就先执行不带total_filtered_score > 0条件的分页查询，拿到结果后在内存里过滤掉不符合条件的数据。注意这种方法可能导致每页实际返回的数据量不足，需要前端配合处理。

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