分页慢主因是count()和select()执行耗时，需先用microtime打点、MySQL慢日志及EXPLAIN定位SQL瓶颈；若PDOStatement::execute耗时超70%，说明数据库层慢；XHProf采样须避开渲染假热点，日志禁用完整数据序列化。
分页慢，先确认是SQL还是PHP逻辑拖慢
ThinkPHP分页本身不慢，慢的是它背后执行的 count() 和 select()。常见现象是：列表页首屏 1.2s，FPM慢日志里反复出现 index.php + 分页控制器方法，但 PDOStatement::execute 耗时占比超 70%——这说明瓶颈在数据库层；如果慢日志里全是 think\db\Query->select 或 think\paginator\driver\Bootstrap->render，才该怀疑PHP侧。
快速验证方式：
- 用
microtime(true)在分页前/后打点，对比$list = $query->paginate(15)的耗时 - 开启 MySQL 慢日志，设
long_query_time = 0.1，看是否命中SELECT COUNT(*) FROM ...或带LIMIT的主查询 - 在控制器中临时加
Log::info($query->buildSql())，把生成的 SQL 拿到 MySQL 客户端里EXPLAIN一把
ThinkPHP分页的N+1问题怎么暴露出来
分页结果集里每个模型调用 getAttr()、relation() 或访问未预加载的关联字段，就会触发额外查询。XHProf 里会看到大量重复的 think\db\Connection->query 调用，且「Inclusive Wall Time」高、「Exclusive Wall Time」低，调用栈深度一致。
典型场景：
立即学习“PHP免费学习笔记（深入）”；
- 模板中写
{$vo.user.name}，但没在分页前加with('user') - 模型的
getXXXAttr方法里又查了一次数据库 - 分页后循环调用
$item->toArray()，而模型里定义了复杂访问器
修复动作要落在分页语句上：$query->with(['user', 'category'])->paginate(15)，不是等数据出来再补救。
XHProf采样必须避开分页的“假热点”
ThinkPHP 8 的分页渲染（比如 Bootstrap 驱动）会动态生成 HTML 字符串，里面包含大量字符串拼接和数组遍历。XHProf 把这些全记进去，容易误判为瓶颈。实际业务逻辑可能只占总耗时 15%，但渲染占了 60%。
精准采样的做法：
- 在中间件
handle()里判断路由是否为分页接口（如匹配/api/list），再启用xhprof_enable(XHPROF_FLAGS_NO_BUILTINS | XHPROF_FLAGS_CPU) - 在控制器中分页调用前手动打点：
$start = microtime(true); $list = $query->paginate(15); Log::debug('paginate time', ['cost' => microtime(true) - $start]); - 避免在
view层或__toString()里启动采样——分页对象转 JSON 或渲染时的开销不反映真实数据获取成本
日志写法不当会让分页变“更慢”
线上开着 APP_DEBUG = true，或者分页逻辑里用了 Log::info('page data', $list->items())，等于把整个分页结果数组序列化进日志文件。尤其当一页返回 15 条含 5 个关联模型的数据，单次日志写入可能超 2MB，I/O 直接卡死。
安全写法：
- 确保
APP_DEBUG = false，且日志驱动不是File，改用Socket或Redis（配置'type' => 'socket'） - 调试分页只记录关键元信息：
Log::debug('paginate', ['total' => $list->total(), 'per_page' => $list->listRows(), 'sql' => $query->getLastSql()]) - 禁止对
$list->items()或$list->toArray()做完整日志输出——它们是对象集合，不是纯数组
最常被忽略的一点：分页性能问题往往不在 paginate() 这一行，而在它前面的 where() 条件是否能走索引、关联预加载是否真正生效、以及日志是否在偷偷吃掉响应时间。
