ThinkPHP 8.0 查询慢八成非框架问题，而是索引缺失、关联查询冗余、未用预编译、分页COUNT(*)低效及类型不匹配导致索引失效；应通过EXPLAIN分析、建合适索引、裁剪关联字段、启用预编译、优化分页策略并校验字段类型。
ThinkPHP 8.0 查询慢，八成不是框架问题，而是 mobile、user_id、status 这类常用 WHERE 字段没建索引，或者 with() 关联查了整张表却只用两个字段——查得越多，内存越爆，响应越卡。
WHERE 条件字段有没有索引？先看 EXPLAIN 再说话
别猜，直接让 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')
with() 关联查了 12 个字段，业务只要 nickname 和 avatar
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）必须逐级声明字段，不能只在第一层裁剪
预编译没开，每次查询都在重复解析 SQL
ThinkPHP 默认的 Db::table()->where()->select() 是字符串拼接，不走 PDO 预编译。高并发下，SQL 解析 + 执行计划生成变成瓶颈。真正启用预编译，得绕过 Query 类，直连 PDO。
立即学习“PHP免费学习笔记（深入）”；
- 手动获取连接：
$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 无法复用执行计划，反而更慢
分页 COUNT(*) 卡住 3 秒，其实根本不需要精确总数
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 写得漂不漂亮。
