ThinkPHP查询慢的首要原因是mobile字段未建索引，导致全表扫描；应先用SHOW INDEX检查并添加单列或联合索引，避免函数操作使索引失效，结合EXPLAIN验证执行计划，必要时手动使用PDO预编译提升高并发性能。
ThinkPHP 查询慢，先确认是不是没走索引
很多同学一遇到 Db::table('user')->where('mobile', $phone)->find() 延迟高，就急着加缓存或换数据库，其实 80% 的情况是字段 mobile 没建索引。MySQL 对无索引的 WHERE 条件会全表扫描，哪怕只有 1 万条数据，平均响应也可能飙到 300ms+。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
SHOW INDEX FROM user检查mobile是否在索引列表里； - 若没有，执行
ALTER TABLE user ADD INDEX idx_mobile (mobile)； - 复合查询（如
where(['status' => 1, 'created_at' => ['>=', $time]])）优先建联合索引，顺序按「等值条件在前、范围条件在后」，例如ADD INDEX idx_status_created (status, created_at)； - 避免对索引字段做函数操作，比如
where('DATE(created_at)', '2024-01-01')会让索引失效，应改用whereBetween('created_at', [$start, $end])。
ThinkPHP 的 query() 和 execute() 不自动预编译，得手动用 PDO
ThinkPHP 默认的 Db::table()->where()->select() 底层走的是普通字符串拼接 SQL，不启用 PDO 预编译（prepared statement）。这意味着每次查询都要经历 SQL 解析、计划生成，高并发下开销明显。真正启用预编译，得绕过 Query 类，直接用底层 PDO 实例。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 获取 PDO 连接：
$pdo = Db::connect()->getPdo();； - 手动 prepare：
$stmt = $pdo->prepare('SELECT * FROM user WHERE mobile = ? AND status = ?');； - execute 传参：
$stmt->execute([$phone, 1]); $result = $stmt->fetchAll(PDO::FETCH_ASSOC);； - 注意：预编译只对「参数位置固定、结构不变」的查询有效；如果 SQL 字符串动态拼了
ORDER BY或LIMIT，PDO 无法复用执行计划，反而可能更慢。
开启 query_log 查看真实执行的 SQL 和耗时
ThinkPHP 的日志里默认不记录每条 SQL 的执行时间，光看 Db::getLastSql() 不知道它到底跑了多久。不亲眼看到执行计划和耗时，优化就是蒙眼走路。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 临时开启 MySQL 的慢查询日志：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.1;； - 在 ThinkPHP 中启用 SQL 日志追踪：
'sql_explain' => true加到数据库配置里，会自动对每条 SELECT 执行EXPLAIN并打印； - 关键看
type字段：出现ALL就是全表扫描，range或ref才算走了索引； - 别信 ThinkPHP 日志里写的「SQL: SELECT …」耗时，那只是 PHP 层面从发起到返回的时间，不含网络和 MySQL 内部排队——真瓶颈得看
SHOW PROFILES或 Performance Schema。
关联查询延迟高？优先考虑 join 拆成两次单表查
ThinkPHP 的 with(['profile', 'orders']) 看起来简洁，但底层是 N+1 查询或一次性 LEFT JOIN。当关联表数据量大、字段多，或者存在 LIMIT 时，JOIN 很容易拖垮性能——MySQL 要先笛卡尔积再过滤，内存和 IO 压力陡增。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 用
Db::name('user')->field('id,name')->select()先取主表 ID 列表； - 再用
Db::name('profile')->where('user_id', 'in', $userIds)->select()单独查关联数据； - PHP 层用
collection($users)->keyBy('id')+foreach ($profiles as $p) $users[$p['user_id']]['profile'] = $p;合并； - 这种写法在多数业务场景下比
with快 2–5 倍，尤其当关联表有几十万行、且你只需要其中一部分用户的数据时。
索引不是建了就完事，要配合 EXPLAIN 看执行路径；预编译不是开了就提速，得确保 SQL 结构稳定；最危险的优化，是没看清慢在哪，就去动框架封装层。
