Laravel 中用 DB::listen() 实时监听 SQL，需在 AppServiceProvider::boot() 注册，回调中获取 $query->sql、bindings 和 time；DB::enableQueryLog() 仅限单请求调试，注意调用时机与内存开销；生产环境应使用 MySQL 慢日志或 Laravel Telescope。
如何在 Laravel 中实时监听并打印执行的 SQL 语句
直接用 DB::listen()，它会在每次查询触发时回调，适合开发期快速定位慢查或意外查询。别依赖日志文件翻找，监听是实时的、可编程过滤的。
常见错误现象：开了 DB::enableQueryLog() 却没调 DB::getQueryLog()，结果啥也没看到；或者在生产环境误开监听导致性能抖动。
- 只在本地或调试环境启用，
APP_DEBUG=true且非生产环境才建议开启 - 监听函数必须注册在请求生命周期早期（比如
AppServiceProvider::boot()），否则中间件或模型初始化后的查询会漏掉 - 回调参数是
$query对象，含$query->sql、$query->bindings、$query->time（毫秒），别直接 echo，用Log::debug()或dump()
DB::listen(function ($query) {
Log::debug($query->sql, $query->bindings);
});Laravel 查看某次查询实际执行的 SQL（带绑定参数）
用 toSql() 方法能拿到预编译后的 SQL 字符串，但注意：它不执行查询，也不替换 ? 占位符——要手动处理绑定值。很多人以为 toSql() 就是“最终 SQL”，结果复制去数据库执行报错。
使用场景：写复杂联查时验证语法，或生成 SQL 供 DBA 审核。
-
toSql()返回的是带?的语句，如"select * from users where id = ?" - 真实参数在
$builder->getBindings()里，需自己拼（尤其注意字符串要加引号、NULL 要转成NULL） - 对
whereDate()、orderByRaw()等方法生成的 SQL，toSql()可能不完整，建议配合监听交叉验证
$sql = User::where('status', 'active')->toSql();
$bindings = User::where('status', 'active')->getBindings(); // ['active']为什么 DB::enableQueryLog() 有时查不到 SQL？
因为 Query Log 是按连接实例维护的，且默认只记录「当前连接」的查询。Laravel 的队列、测试、多数据库连接或长生命周期命令（如 php artisan tinker）中容易失效。
性能影响明显：开启后每次查询都要追加到内存数组，高并发下可能 OOM；所以它只适合单次请求调试，比如控制器里查完立刻取日志。
- 必须在查询前调用
DB::enableQueryLog()，不能写在中间件或全局启动里指望“一直有效” - 查询后立即用
DB::getQueryLog()获取，延迟调用可能被后续查询覆盖（尤其用了连接池或重连） - 如果用了
DB::transaction()，事务内查询会记入日志，但回滚后日志还在——日志不反映执行结果，只反映发出过什么语句
线上环境安全查看 SQL 的替代方案
生产环境绝不能开 DB::listen() 或 enableQueryLog()。真要排查，优先用数据库原生慢日志（MySQL 的 slow_query_log）或 APM 工具（如 Laravel Telescope 的生产模式部署，但需严格权限隔离）。
容易被忽略的点：Telescope 默认只存最近 100 条查询，且 TELESCOPE_ENABLED=false 时完全不工作；而 MySQL 慢日志需要设置 long_query_time=1 才捕获超过 1 秒的语句——很多 N+1 查询其实单次很快，但总量大，这类问题只能靠应用层监听或链路追踪发现。
