站点访问慢的时候，大多数人先想到加索引、加缓存，实际上问题常出在查询写法上。ThinkPHP6 的查询构造器和模型关联给了很多便利，同时也容易把执行计划带偏。日常排错比较管用的步骤，集中在这几块：确认现象、识别误判、改查询、验证回滚。

先确认现象，再动手改代码

不急着改代码，先确认当前请求真的存在多余查询。打开 Debug 模式，页面底部的工具栏会列出本次请求执行的 SQL 数量和语句列表。在 config/app.php 里开启 app_debug，或者把 .env 里的 APP_DEBUG 设为 true，刷新一次页面就能看到。

在 ThinkPHP6 中，如果模型关联查询时循环获取关联数据，会触发 N+1 查询。开启 Debug 日志观察执行的 SQL 数量，当记录数为 n 时，SQL 总数为 1+n（主查询加上每条记录关联查询）即可确认。解决方法是使用 with 预加载，如 User::with('orders')->select()，这样只执行两次查询。注意 with 中的关联条件若带参数，需使用闭包，不能直接传参，否则可能报错。

当记录数只有几条时，1+n 次查询感觉不出来；一旦列表页记录数到几百条，响应时间就会被关联查询拖垮。with 预加载的核心是把多次关联查询合并成一次 IN 查询，前提是关联字段上有索引。注意 with 只对当前模型的关联方法生效，如果关联方法内部依赖外部参数，比如按订单状态筛选，就必须用闭包传参。直接把数组丢给 with，框架会把数组当成关联方法参数处理，通常会报参数绑定错误。

容易误判的地方

很多优化建议把 select * 当成主要矛盾，实际在字段少的数据表里，select * 和指定字段的性能差异并不明显。真正的开销来自大字段传输和 ORM 层的数据处理。

使用查询构造器时，建议用 field 方法指定查询字段，如 Db::name('user')->field('id,name,email')->select()，避免 select * 带来的不必要的数据传输和内存占用。当表结构包含大字段（如 text、blob）时，这种优化效果明显。如果只需要单条记录，用 find 替代 select，并确保 where 条件能唯一过滤。find 查询不到时返回 null，而 select 返回空数组，后续处理需要区分类型。

field 方法减少的是网络传输和框架内部的数据处理量，而不是查询次数。如果表里没有大字段，只为了少取两列去改 field，收益很有限。find 返回 null，select 返回空数组，这个差异在接口层容易埋雷。统一返回格式时，用 count($result) 判断还好；直接取 $result['name']，null 和空数组都会报错，只是报错信息不一样，排查时要先分辨是哪一种。

建议的处理顺序

改查询条件之前，先把真实执行的 SQL 抓出来。

优化前先获取真实执行的 SQL，可以调用 Db::name('user')->where('status',1)->fetchSql(true)->select()，这条链式不会真正执行，而是返回 SQL 字符串。将 SQL 复制到数据库客户端，用 EXPLAIN 查看执行计划。如果 type 不是 ref 或 range，而是 ALL 或 index，说明没有走索引，需要在 where 条件涉及的字段上建立索引。注意 fetchSql 返回后不能再链式调用其他查询方法，否则会报错。此方法适合调试单条语句，批量测试时用日志更高效。

fetchSql 适合在控制器里临时调试单条语句。SQL 字符串里保留的是预处理占位符，复制到数据库客户端时，要手动替换成实际参数，否则 EXPLAIN 看到的执行计划可能失真。type 为 ALL 说明全表扫描，type 为 index 说明扫描了索引树，这两种情况都需要继续检查 where 条件是否覆盖了索引列。

EXPLAIN SELECT * FROM user WHERE status = 1;

如果 where 条件里用了函数或隐式类型转换，索引也会失效。比如在日期字段上套 DATE() 函数，换成区间查询通常能恢复索引扫描。

分页和缓存的边界

分页代码里最隐蔽的开销是 count。ThinkPHP6 的 paginate 会自动执行 count，数据量小的时候无感，数据量大或 where 条件里带 join、子查询时，count 可能比列表查询本身还慢。simplePaginate 只返回当前页和下一页标记，适合资讯类站点的加载更多场景。如果页面必须展示总页数、总条数，count 省不掉，能做的就是把 where 条件涉及的字段索引补齐。带 group by 的分页，count 结果经常不准，需要先手动写一条查询取 total，再查当前页数据，避免返回错误的页数给前端。

缓存方面，Db 链式查询的 cache 方法适合读取频繁、更新不频繁的数据。但缓存不会随数据表更新而自动失效，需要手动清除。建议给缓存设置 tag，更新数据时按 tag 统一清理，避免页面出现明显脏数据。缓存设置过长时间，用户看到的数据和实际数据库相差太大，问题排查起来反而困难。

验证方法与回滚

优化完成之后，重复打开同一个页面，对比 Debug 工具栏里的 SQL 数量和单条 SQL 的执行时间。SQL 数量从 1+n 降到 2，说明预加载生效；字段优化是否有效，看 EXPLAIN 里的 key 是否指向了预期索引。实际操作中，我一般改一个点验证一次，逐项推进，而不是把所有优化堆到一起再排查。

回滚边界也要提前想好。从 paginate 改成 simplePaginate，接口返回的数据结构会变化，前端如果依赖 total 字段，这个改动就不是单纯改一行代码能回滚的，需要前后端一起处理。所以调整分页前，先确认接口调用方是否真的不需要总页数，避免优化完又要返工。模型关联改为 with 预加载后，关联数据的排序和过滤逻辑也要同步检查，避免因查询合并导致结果顺序不一致。

ThinkPHP6 的查询优化，核心还是把真实执行的 SQL 看清楚。Debug 日志、fetchSql、EXPLAIN 这几个工具组合着用，能覆盖大部分场景。框架本身没有银弹，先确认现象，再做最小改动，每步都验证，是相对稳妥的处理顺序。