在 ThinkPHP 8 中监听慢 SQL 需在连接初始化后、首次查询前调用 Db::listen() 注册监听器，接收 $sql、$time、$explain 参数，从配置读取阈值判断慢 SQL；事务中默认合并事件，需关闭预处理模拟或手动记录时间；写日志应使用独立异步通道并包含调用栈与请求 URL；EXPLAIN 需按条件安全触发，生产环境推荐 MySQL 原生慢日志。
如何在 ThinkPHP 8 中监听慢 SQL 并触发自定义逻辑
ThinkPHP 8 的数据库底层已内置 think\db\Connection 事件机制，慢 SQL 监控不依赖中间件或手动埋点，直接监听 sql_express 事件即可捕获每条执行完毕的 SQL 及其耗时。关键在于：必须在连接初始化后、首次查询前注册监听器，否则会漏掉早期 SQL。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/bootstrap.php或服务提供者register()方法中调用Db::listen()，不要放在控制器里 - 回调函数接收三个参数：
$sql（原始语句）、$time（毫秒，float）、$explain（执行计划数组，可选） - 判断慢 SQL 不要用固定阈值硬编码，推荐从配置读取：
config('database.slow_sql_threshold', 500) - 注意：该事件只触发「成功执行」的 SQL；超时、断连、语法错误等异常情况不会进入此回调
为什么 Db::listen() 捕获不到事务中的慢查询
事务内多条 SQL 默认被合并为一个 sql_express 事件（尤其在 PDO 的 PDO::ATTR_EMULATE_PREPARES = false 下），导致无法精确定位哪条语句慢。这不是 Bug，而是底层驱动对事务批次执行的优化表现。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 如需逐条监控，关闭预处理模拟：
'options' => [PDO::ATTR_EMULATE_PREPARES => true]（仅开发/测试环境启用） - 生产环境更稳妥的做法是：在事务开始前手动记录起始时间，
commit()或rollback()后遍历Db::getLog()获取所有语句及时间戳 - 避免在事务中执行非必要查询——这是比监听更有效的“慢 SQL 治本”方式
写入慢 SQL 日志时容易踩的磁盘 I/O 坑
直接用 file_put_contents(..., FILE_APPEND) 写日志，在高并发下极易阻塞主线程，甚至拖垮整个应用。ThinkPHP 自带的日志通道（如 FileChannel）虽有缓冲，但默认不区分慢 SQL 日志级别，会导致慢日志和普通 debug 日志混在一起，检索困难。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 为慢 SQL 单独配置日志通道，在
config/log.php中新增'slow_sql'驱动，指定独立文件路径：'path' => runtime_path() . 'log/slow_sql/' - 禁用该通道的
realtime_write，改用异步写入（如通过Swoole\Coroutine\writeFile，若项目已集成 Swoole） - 日志内容至少包含：
$sql、$time、debug_backtrace(0, 3)（定位调用位置）、Request::instance()->url()（关联请求） - 务必设置文件轮转：
'max_files' => 30，防止单个日志无限增长
如何让慢 SQL 日志自动包含执行计划（EXPLAIN）
ThinkPHP 不自动执行 EXPLAIN，但提供了钩子入口。在 Db::listen() 回调中直接调用 Db::query('EXPLAIN ' . $sql) 是危险操作——可能引发死循环（再次触发监听）、或因权限不足报错 SQLSTATE[42000]: Syntax error or access violation。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 只对
SELECT开头的语句做 EXPLAIN，且加try/catch包裹，失败则跳过 - 限制 EXPLAIN 频率：用
md5($sql)做缓存键，1 小时内相同 SQL 最多记录一次执行计划 - 生产环境慎用：EXPLAIN 本身有开销，尤其对大表 JOIN，建议仅在调试阶段开启全局，或按需通过请求参数（如
?explain=1）动态激活 - 替代方案：用 MySQL 的
slow_query_log+long_query_time配合log_queries_not_using_indexes，更底层、更稳定
慢 SQL 监控真正的复杂点不在代码怎么写，而在于「什么时候不该记录」——比如定时任务里的批量更新、后台导出的临时查询，它们天然耗时长，但不属于业务瓶颈。过滤规则比采集逻辑更需要持续迭代。
