应分两次独立查询获取总记录数和分页数据，避免使用已废弃的sql_calc_found_rows；count条件须与分页where完全一致，并通过预处理防注入；分页类中延迟加载总数，前端显示时注意缓存一致性与过期策略。
分页前先查总记录数，别用 SQL_CALC_FOUND_ROWS
直接在分页 SQL 前加一条 SELECT COUNT(*) 最稳妥。很多教程还在推 SQL_CALC_FOUND_ROWS，但它在 MySQL 8.0+ 已被标记为废弃，且在有 LIMIT + 复杂 JOIN 或索引不当时，性能反而更差，结果还可能不准。
实操建议：
- 写两个独立查询：第一个查总数（
SELECT COUNT(*) FROM table WHERE ...），第二个查分页数据（SELECT * FROM table WHERE ... LIMIT ?,?） - WHERE 条件必须完全一致，否则总数和分页数据对不上
- 如果条件含用户输入，记得统一用 PDO 预处理，避免拼接导致逻辑错位
PHP 分页类里怎么安全暴露总记录数
别把 $total 当作类属性直接 public 暴露，也别在构造函数里一次性查完所有数据再算总数——那样会浪费内存，尤其数据量大时。
推荐做法：
立即学习“PHP免费学习笔记（深入）”；
- 在分页类中设一个私有属性
$totalRecords，只在首次调用getTotal()时执行 COUNT 查询 -
getTotal()方法内部加判断：if ($this->totalRecords === null) { $this->totalRecords = $this->runCountQuery(); } - 对外提供
getTotal()和getPageCount()（即ceil($total / $limit)），不暴露原始查询逻辑
前端显示“共 X 条”时注意缓存与并发
总记录数不是静态值，它会随增删改实时变化。如果你用了 Redis 缓存分页结果，但没连带缓存或失效 COUNT 结果，前端就可能显示“共 120 条”，点到最后一页却只有 115 条数据。
关键控制点：
- 写操作（INSERT/UPDATE/DELETE）后，主动删除对应列表的 COUNT 缓存键，比如
cache_delete('user_list_count_v1') - 不要给 COUNT 结果设过长 TTL，尤其高写入场景下，5–30 秒足够；宁可多查一次，别显示过期总数
- 如果业务允许弱一致性，可以在分页接口返回时加字段
"total_estimated": true，提醒前端该总数是近似值
用 Laravel 的 paginate() 怎么拿到准确总数
Laravel 的 paginate() 默认会自动执行 COUNT 查询，但有个隐藏坑：当你手动加了 groupBy、distinct 或子查询，它可能抛出 SQLSTATE[HY000]: General error: 1140 In aggregated query without GROUP BY。
解决路径：
- 优先用
simplePaginate()：它不查总数，只判断是否有下一页，适合大数据集或不需要“共 X 条”的场景 - 若必须用
paginate()且含复杂查询，改用DB::select()手动执行 COUNT，再传给LengthAwarePaginator构造函数 - 检查是否误用了
->toBase()或->getQuery()中途截断了查询结构，导致 COUNT 语句生成失败
总记录数看着简单，但它是分页链上最易松动的一环——查得不准、缓得不当、传得不稳，都会让“第 3 页，共 12 页”变成一句不可信的提示。
