Laravel 9/11 数据库查询日志对比：慢查询监控与SQL语句记录的配置【详解】

Lara vel 9 和 11 在数据库查询日志与慢查询监控上，核心能力其实一脉相承。但到了 Lara vel 11，配置方式、连接级开关、DB::listen() 字段的稳定性以及可观测性集成都有了明显优化。所以，更推荐的做法是：用 DB::listen() 结合环境自动过滤和日志通道，既能实现精准监控，又不会给线上带来额外开销。

Lara vel 9 和 11 在数据库查询日志与慢查询监控方面，核心能力总体一致，但配置方式、默认行为和集成深度有明显演进。重点不是“能不能记录”，而是“怎么更准、更稳、更易用”——尤其是在开发调试与线上可观测性之间找到平衡点。

本地调试：启用方式更统一，但推荐做法没变

两者都支持 DB::enableQueryLog() 动态开启，也都能通过 DB::listen() 实时捕获每条 SQL。区别在于：

• Lara vel 9 需要在 AppServiceProvider@boot 中手动加上环境判断（比如 if (app()->environment('local'))），再调用 enableQueryLog() 或注册监听器；而 Lara vel 11 默认鼓励用 DB::listen() + 日志通道，配合环境自动过滤，避免误开导致性能抖动。
• 两者都不会自动把 bindings 拼接到 SQL 字符串中，仍然需要手动替换问号占位符才能看到真实值。
• DB::getQueryLog() 返回的仍然是当前请求生命周期内的所有查询，而且只包含默认数据库连接的日志——读写分离场景下，主从库日志需要分别处理。

慢查询识别：框架层不替代 MySQL 层，但可辅助定位

Lara vel 自身并没有“慢查询阈值”的概念，它只记录执行时间（$query->time 单位毫秒），是否算“慢”由开发者自己定义。常见做法是：

• 在 DB::listen() 回调中判断是否超过阈值（比如 if ($query->time > 100)），然后记录到日志或触发告警。
• 不建议在生产环境全局启用 enableQueryLog()，因为它的开销相当可观。
• 真正可靠的慢查询来源还是 MySQL 的 slow_query_log，Lara vel 日志的价值在于帮你快速关联业务逻辑——比如某次请求对应哪几条慢 SQL。
• Lara vel 11 对 DB::listen() 的事件对象字段更加稳定（sql、bindings、time、connectionName 都明确可用），便于构建轻量级监控钩子。

配置粒度：Lara vel 11 支持连接级开关，更贴近实际部署

从 Lara vel 10.30 开始，config/database.php 中就可以为单个数据库连接设置 'logging' => true，Lara vel 11 延续并强化了这项能力：

• 允许只对 mysql 连接开启日志，而 pgsql 或 redis 不受影响。
• 配合 APP_ENV=local 或 APP_DEBUG=true 条件启用，避免硬编码。
• 如果使用多租户或多数据库架构，可以按连接名动态控制日志行为，比 Lara vel 9 的全局开关更安全可控。
• 注意：该配置仅影响 Query Builder 和 Eloquent 查询，原生 PDO 或 DB::raw() 不会走日志管道，不会被记录。

可观测性增强：从日志到工具链的衔接更顺

Lara vel 11 并没有内置慢查询分析器，但它与现代可观测工具的对接更加自然：

• 原生兼容 Lara vel Telescope（需要单独安装），可以直接查看带执行时间、绑定参数、上下文堆栈的完整 SQL。
• DB::listen() 输出结构清晰，容易对接 Sentry、Datadog 等 APM 工具做聚合统计（比如按 route、controller、SQL 模板分组）。
• 配合 MySQL 的 log_queries_not_using_indexes = ON，能提前发现“快但危险”的无索引查询——这类语句在 Lara vel 日志里可能只有几十毫秒，却已经在拖垮数据库。
• 推荐的组合策略：MySQL 慢日志抓全貌 + Lara vel listen 抓上下文 + EXPLAIN 分析执行计划，三者缺一不可。