排查利器：Laravel循环慢查询定位-php教程-PHP中文网

db::listen()必须在appserviceprovider::boot()中注册，才能全局捕获所有sql执行上下文；它可精准监听循环中的每次查询，获取真实参数、耗时及连接信息，而db::enablequerylog()仅限单请求且不记录绑定值，无法应对foreach等高频场景。

排查利器：laravel循环慢查询定位

DB::listen() 必须在 boot() 里注册

循环慢查询往往藏在 foreach、map 或 collection 操作里，DB::enableQueryLog() 在这类场景下基本失效——它只捕获当前请求生命周期内的查询，且不记录绑定参数的实际值，调试时根本看不出是哪次循环触发了哪条 SQL。

DB::listen() 才是真正在循环中抓到“每一次执行”的唯一可靠方式。它监听所有数据库连接事件，不受作用域限制，能拿到 $query->sql、$query->bindings、$query->time 和调用栈 $query->connection->getPdo()->getAttribute(PDO::ATTR_DRIVER_NAME)（可推断是否为 MySQL）。

必须放在 AppServiceProvider::boot() 中注册，register() 阶段太早，DB 连接尚未初始化
别写成闭包里调用 dd() 或 dump()，会中断循环流程，掩盖真实执行路径
日志要写入独立文件（如 storage/logs/loop-queries.log），避免和业务日志混在一起，grep 时难定位
高频但单次快的查询（如 SELECT * FROM users WHERE id = ? 耗时 12ms）比单次慢的更危险，需统计出现次数而非只盯 time > 1000

日志里带问号的 SQL 怎么验索引

直接把日志里的 SELECT * FROM posts WHERE user_id = ? AND status = ? 粘进 phpMyAdmin 执行 EXPLAIN，结果 type=ALL 并不能说明线上也全表扫描——MySQL 优化器对问号不做估算，实际执行计划取决于参数值。

真正有效的验证方式是：从日志中挑出一次具体调用，比如 user_id = 42 AND status = 'published'，手动拼成完整语句再 EXPLAIN SELECT * FROM posts WHERE user_id = 42 AND status = 'published'。

重点看 key 是否非 NULL、rows 是否远小于表总行数（如 rows=9800，而表只有 500 行，说明索引没生效）
Extra 出现 Using filesort 或 Using temporary 是典型信号，尤其出现在带 ORDER BY created_at DESC LIMIT 20 的分页查询里
联合索引顺序必须匹配 WHERE 条件顺序：INDEX(user_id, status) 有效，INDEX(status, user_id) 对该查询无效
软删除字段 deleted_at 参与查询（如 WHERE deleted_at IS NULL）必须单独建索引或包含在联合索引最右位

Debugbar 的重复查询警告怎么用

Debugbar 在循环慢查询场景下不是“锦上添花”，而是“救命稻草”——它会在 Database 面板里把相同 SQL 的多次执行标为橙色，并显示 Duplicates: 47，这比自己写脚本统计日志快得多。

Laravel 13.2.0

PHP中文网提供Laravel 13.2.0版本下载，Laravel框架是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。

下载

但它有个致命盲区：只在当前 HTTP 请求内生效，且依赖 APP_DEBUG=true，不能进生产环境。所以它的价值在于快速复现 + 定位代码行，而不是长期监控。

点击高亮 SQL 后看 Call Stack，能精准跳到 Blade 模板里 {{ $user->avatar }} 这一行，或控制器里 $users->each(...) 的闭包位置
如果看到 SELECT * FROM users WHERE id = ? 出现几十次，基本就是 N+1 或未预加载，立刻查对应模型的 with() 是否漏写
别信 “Time (ms)” 列的平均值，要看单条耗时分布——有些循环第 1 次快（命中缓存），后面越来越慢（锁竞争或临时表膨胀）
关闭 Debugbar 的 collectors 配置里 default 以外的项（如 cache、views），否则内存占用飙升，反而掩盖真实瓶颈

加索引为什么线上跑迁移会卡死

在百万级用户表上执行 Schema::table('users')->index('status')，MySQL 默认会锁整张表，期间所有读写请求排队等待，页面直接 504。这不是 Laravel 的锅，是底层数据库行为。

Laravel 迁移本身不提供在线 DDL 支持，得靠数据库原生命令或工具兜底。

MySQL 5.6+ 用 ALGORITHM=INPLACE, LOCK=NONE（需确认存储引擎支持）
生产环境优先走 pt-online-schema-change 或 gh-ost 工具，而不是直接跑 php artisan migrate
外键字段、软删除字段、常用于 WHERE 和 ORDER BY 的组合字段，必须提前规划索引，别等慢了再补
联合索引不是越多越好：INDEX(a,b,c) 能覆盖 WHERE a=? 和 WHERE a=? AND b=?，但不能覆盖 WHERE b=?，冗余索引反而拖慢写入