分页必须查总数是因为前端分页控件需 total 计算页码、禁用状态及最后一页；不查则仅支持上下页，如 thinkphp 的 paginate(20, false)；count(*) 慢源于全表扫描，非语法本身。
为什么分页必须查总数？前端要算页码和导航
不是框架“非要”查 COUNT(*)，而是前端分页控件（比如 Bootstrap Pagination、Element UI 的 el-pagination）需要知道 total 才能渲染出「共 127 页」「当前第 3 / 127 页」「下一页是否禁用」这些逻辑。没有总数，就无法计算 lastPage，也无法判断用户点「最后一页」该跳到哪个 offset。
不查总数会怎样？ThinkPHP 的 paginate(20, false) 就是答案
关掉总数统计后，$list->lastPage() 返回 null，$list->render() 只生成「上一页 / 下一页」按钮，不显示数字页码——这恰恰是多数列表页的真实需求：用户只往前翻几页，或无限滚动/下拉加载，根本不需要跳转到第 89 页。
- 模板里必须用
{$list->render()}，不能用{$list->show()}（会报错） - 判断是否还有下一页，改用
$list->hasMore() - 带搜索参数时，得手动传
['query' => request()->only(['q', 'status'])]，否则翻页后参数丢失
COUNT(*) 慢在哪？不是函数本身，是它被迫扫全表
慢的从来不是 COUNT(*) 这个语法，而是它在复杂查询里没法走索引：
- 带
JOIN却没给关联字段建索引 →EXPLAIN显示type = ALL - 用了软删除但 WHERE 没写
delete_time IS NULL→ 扫描所有已删和未删行 - 加了
GROUP BY或HAVING→ MySQL 无法优化 COUNT，只能临时表+全扫 - 深分页如
LIMIT 50000, 20→COUNT(*)和主查询各自扫描前 5 万行，IO 翻倍
缓存 COUNT(*) 不是万能解，键设计错了反而更糟
缓存只对「低频变更 + 查询条件稳定」的场景有效，且极易脏数据：
- 用户列表总数缓存键建议含筛选维度，比如
user_count_status_1，而不是笼统的user_count - 软删除未过滤、状态字段没进 WHERE 条件 → 缓存键无法穷举，一缓就错
- 高并发写入时，别用
GET + SET更新缓存，必须用INCR/DECR原子操作 - MySQL 8.0+ 已废弃
SQL_CALC_FOUND_ROWS，别再为兼容旧版硬套
真正的大数据量分页，游标分页（基于 id > ? ORDER BY id ASC LIMIT 20）才是绕过 COUNT 和 OFFSET 双重开销的正路——只是它要求放弃任意页跳转能力。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
