Laravel自定义分页下仅取前N条时，高效获取查询总条数的方法

首先明确一个核心事实：不存在任何方案能在拉取分页列表数据的同时，零开销顺带获取全量符合条件的总条数。哪怕是Laravel原生的paginate()方法，内部也是拆分两次独立SQL执行：先跑一次去掉limit/offset的count查询拿总数，再跑一次带分页参数的列表查询，没有所谓的“魔法”能绕过这个逻辑。
真正的优化方向从来不是“想办法消除count查询”，而是尽可能压缩count查询的执行开销，避免让它和列表查询一样重、一样慢。

可落地的效率优化手段 #

• 裁剪count查询的冗余配置，减少无意义的执行开销
  用克隆查询直接跑count的写法，很容易因为残留列表场景的配置，导致count查询比实际需要的更重：比如残留的排序逻辑、预加载关联配置、非必要的select字段指定、之前不小心加上的分页参数，这些内容对获取总数完全没有帮助，反而会增加SQL执行成本。
  改造时只要在克隆的查询实例上，移除这些无关配置即可，参考代码：

  $baseQuery = MyModel::where('field', 'stuff')
      ->where('some other complex subquery');
  
  // 裁剪后的轻量count查询
  $totalCount = (clone $baseQuery)
      ->setEagerLoads([]) // 清空所有预加载关联，防止count查询连带触发关联表查询
      ->reorder() // 移除全部排序条件，count场景下排序无实际意义
      ->limit(0)
      ->offset(0)
      ->count(MyModel::getPrimaryKey()); // 用主键计数替代count(*)，InnoDB引擎下执行效率更高
  
  // 原查询不受克隆实例影响，直接追加分页参数即可
  $items = $baseQuery->limit($limit)
      ->offset($offset)
      ->get();
  

• 匹配筛选条件建联合索引，从数据库执行层面降低count成本
  多数场景下count查询慢，本质不是SQL结构不合理，而是筛选条件没有命中有效索引，导致数据库需要全表逐行扫描。只要针对固定的筛选条件搭建匹配的联合索引，count查询和列表查询都会直接命中索引，执行速度会从秒级降到毫秒级，这个优化的收益远高于代码层面的零散调整。

• 对精度要求不高的场景，用估算值或缓存替代实时精确count
  如果业务不需要完全精确的总条数（比如后台管理分页条、C端内容列表，用户对几十条的页数差没有强感知），完全可以砍掉实时count的开销：
  可以直接用MySQL InnoDB引擎自带的表统计值做简单的总数估算，也可以把之前计算的总数缓存5-10分钟，不需要每次翻页都实时重算，用户基本感知不到延迟。

• 极端重查询场景下，用单轮流式扫描替代双次查询
  如果筛选逻辑实在过于复杂，跑一次count的开销和跑一次全量列表差不多，就换个思路：直接去掉limit/offset，用Laravel的cursor()或lazy()方法做流式读取，拉取全量符合条件的记录，读取过程中逐行计数，同时截取当前分页需要的段落。
  这种方案只需要一次全表扫描，比“双次全表扫描（一次count、一次带分页的列表）”的总开销少一半。实操时要注意必须用流式读取，不能一次性把全量结果加载到内存，避免内存溢出。

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