ThinkPHP 8.0 为何查询速度慢？一文看懂索引与预加载【性能】-ThinkPHP-PHP中文网

ThinkPHP 8.0 查询慢八成非框架问题，而是索引缺失、关联查询冗余、未用预编译、分页COUNT(*)低效及类型不匹配导致索引失效；应通过EXPLAIN分析、建合适索引、裁剪关联字段、启用预编译、优化分页策略并校验字段类型。

thinkphp 8.0 为何查询速度慢？一文看懂索引与预加载【性能】

ThinkPHP 8.0 查询慢，八成不是框架问题，而是 mobile、user_id、status 这类常用 WHERE 字段没建索引，或者 with() 关联查了整张表却只用两个字段——查得越多，内存越爆，响应越卡。

别猜，直接让 MySQL 告诉你它怎么查的。在数据库配置里加 'sql_explain' => true，TP 就会对每条 SELECT 自动执行 EXPLAIN 并打日志。

重点盯 type 字段：出现 ALL 就是全表扫描，哪怕只有 1 万行，平均延迟也可能飙到 300ms+
mobile 字段没索引？立刻跑：ALTER TABLE user ADD INDEX idx_mobile (mobile);
复合条件如 where(['status' => 1, 'created_at' => ['>=', $time]])，建联合索引要按「等值在前、范围在后」：ADD INDEX idx_status_created (status, created_at)
避免函数操作导致索引失效：用 whereBetween('created_at', [$start, $end])，别写 where('DATE(created_at)', '2024-01-01')

User::with('profile') 默认会查 profile 表全部字段，100 个用户就拖进内存 1200 个字段，还容易触发 N+1。裁剪必须作用在关联模型本身，不能靠主模型 field() 加点号语法。

硬编码方式（适合固定需求）：在 User 模型的 profile() 方法末尾加 ->field(['id', 'user_id', 'nickname', 'avatar'])；注意 user_id 是外键，必须显式包含，否则关联结果为 null
动态方式（推荐）：User::with(['profile' => function ($q) { $q->field(['user_id', 'nickname']); }])；每个关联闭包必须独立调用 field()，不能复用同一 $q
三层关联（如 User → Profile → AvatarLog）必须逐级声明字段，不能只在第一层裁剪

ThinkPHP 默认的 Db::table()->where()->select() 是字符串拼接，不走 PDO 预编译。高并发下，SQL 解析 + 执行计划生成变成瓶颈。真正启用预编译，得绕过 Query 类，直连 PDO。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

手动获取连接：$pdo = Db::connect()->getPdo();
预编译语句：$stmt = $pdo->prepare('SELECT * FROM user WHERE mobile = ? AND status = ?');
传参执行：$stmt->execute([$phone, 1]); $result = $stmt->fetchAll(PDO::FETCH_ASSOC);
注意：预编译只对结构固定的 SQL 有效；如果 ORDER BY 或 LIMIT 是动态拼的，PDO 无法复用执行计划，反而更慢

ThinkPHP 分页默认先 COUNT(*) 再 LIMIT，500 万行的表，COUNT(*) 可能跑满 3 秒。用户还没看到第一页，请求就超时了。

关闭自动 count：paginate(15, false, ['query' => request()->param()])，自己用 Redis 缓存总数或返回近似值
真要精确且数据量大，把 COUNT(*) 改成覆盖索引查询，例如 SELECT COUNT(user_id) FROM user WHERE status = 1（前提是 user_id 非空且有索引）
前端限制最大页码，后端加守门逻辑：if ($page > 2000) { throw new HttpException(400); }

最容易被忽略的是：索引建了但字段类型不一致（比如 PHP 传字符串，DB 字段是 INT），或者字符集不同（utf8mb4 vs utf8），都会让索引静默失效。上线前务必用 EXPLAIN 实测真实执行计划，而不是只看 SQL 写得漂不漂亮。