ThinkPHP6高并发慢查询排查需分层定位：先确认MySQL原生日志真实开启（long_query_time≤0.2s）、再用pt-query-digest聚合分析Top SQL模板、接着通过Db::listen与日志上下文绑定业务链路、最后用EXPLAIN验证key/rows/Extra三列执行瓶颈。
ThinkPHP6 面对 1 万并发时，数据库慢日志排查不能只靠“看日志”，必须分层定位：先确认慢查询是否真实发生，再锁定是 SQL 本身问题、执行环境异常，还是框架层干扰。核心在于“MySQL 原生日志为据、TP 上下文为线、EXPLAIN 为证”。
一、确保 MySQL 慢日志真实开启并捕获到高并发下的慢 SQL
并发压测时，大量请求可能瞬间打满连接或触发锁等待，但默认 long_query_time=10 秒根本捕不到真实瓶颈。必须调低阈值并验证写入有效性：
- 临时生效（立即捕获）：
SET GLOBAL slow_query_log = ON;+SET GLOBAL long_query_time = 0.2;（0.2 秒已能暴露多数索引缺失或锁竞争） - 永久配置需在
my.cnf的[mysqld]下添加：slow_query_log=ON、long_query_time=0.2、log_queries_not_using_indexes=ON（强制记录无索引查询） - 检查日志路径权限：
ls -l /var/log/mysql/slow.log，确保mysql用户可写；若用容器，注意挂载卷权限和 SELinux 限制 - 压测中实时追查：
tail -f /var/log/mysql/slow.log | grep -E "(Query_time|Rows_examined|Lock_time)"，快速识别高耗时、高扫描、高锁等待的语句
二、用 pt-query-digest 精准归类高频慢 SQL 模板
1 万并发下，同一条 SQL 可能被调用数千次，原始日志全是重复条目。直接人工翻阅无效，必须聚合分析：
- 安装后执行：
pt-query-digest --since "2026-08-17 12:00:00" /var/log/mysql/slow.log（加时间范围避免历史噪音） - 重点看顶部 Profile 表格：按
Query_time总耗时排序，首行即最大瓶颈；再看Count列——高频低耗时 SQL（如每条 0.1s，但调用 5000 次）总耗时可能远超单条 2s 的 SQL - 逐条分析关键字段：
Rows_examined远大于Rows_sent→ 全表扫描或索引失效；Lock_time占比高 → 锁竞争（尤其 UPDATE/DELETE 集中某几行）；Query_time波动大 → 可能受缓存、锁、数据分布影响
三、在 ThinkPHP 中注入上下文，把慢 SQL 和业务链路对齐
仅知道 SELECT * FROM order WHERE user_id = ? 慢没用，必须知道是哪个用户、哪个接口、哪个定时任务在调用。TP6 需主动埋点：
立即学习“PHP免费学习笔记（深入）”；
- 在
config/database.php开启绑定日志：'log' => ['level' => ['sql'], 'bind' => true]，确保参数值与占位符一起记录 - 在全局中间件（如
app/middleware/LogContext.php）中统一注入：Log::record('SQL Context: ' . request()->url() . ' | UID:' . (session('user_id') ?: 'cli') . ' | TraceID:' . request()->header('x-trace-id', uniqid()), 'sql'); - 若使用 Db::listen，回调中可提取当前控制器/方法：
Db::listen(function ($sql, $time, $explain) { $info = \think\facade\App::debug() ? debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 1)[0] : []; Log::sql("[$info[class]::$info[function]] $sql | time:$time ms"); });
四、结合 EXPLAIN 验证执行计划，拒绝“我以为走了索引”
从慢日志拿到 SQL 后，不能直接改代码。必须在相同数据量、相同 MySQL 版本下执行 EXPLAIN FORMAT=JSON，紧盯三列：
-
key 为空？→ 索引未命中：检查字段类型是否匹配（如传字符串查 INT）、是否在索引列上用了函数（
WHERE DATE(create_time) = '2026-08-17'）、联合索引是否违反最左前缀 - rows 过大？→ 扫描行数远超返回结果：说明索引选择性差，或条件过滤率低；尝试加覆盖索引（把 SELECT 字段也包含进索引）
-
Extra 出现
Using filesort或Using temporary？→ ORDER BY/GROUP BY 无法利用索引排序，需重写逻辑（如用索引字段排序+游标分页）或建组合索引 - 特别注意 TP6 的
whereIn：若传入数组超 500 项，MySQL 可能放弃索引走全表扫描；应主动分批（array_chunk($ids, 500)）或改用临时表关联
不复杂但容易忽略
