怎么在phpMyAdmin排查Laravel队列长时间挂起_分析Reserved

最直接线索是reserved_at有值但远超retry_after未完成：查jobs表中reserved_at is not null且与available_at差值大于retry_after（如设90秒却差15分钟），表明worker崩溃或卡死；需结合redis实际状态（llen queues:default:reserved）及配置一致性排查。

查 `jobs` 表里 `reserved_at` 和 `available_at` 的差值

队列任务卡住最直接的线索就是 reserved_at 有值但没执行完——说明它被某个 worker 拿走了，却迟迟没完成或没释放。先确认是不是真“挂起”：用 phpmyadmin 打开 jobs 表，筛选 reserved_at is not null，再看 reserved_at 和 available_at 的时间差。如果差值远大于你设的 retry_after（比如设了 90 秒，但差了 15 分钟），基本能断定 worker 崩了或卡死在某处。

available_at 是任务本该可执行的时间（入队时计算）
reserved_at 是 worker 开始处理的时间（由 php artisan queue:work 更新）
正常流程中，reserved_at 到 deleted_at 或 released_at 应该在 retry_after 秒内完成

检查 Laravel 队列配置里的 `retry_after` 和 `timeout` 是否冲突

常见坑是 retry_after 设太短（如 30 秒），而实际任务耗时超 30 秒，worker 还没跑完就被认为“失败”，自动释放回队列；接着又被抢走、又超时……形成循环挂起假象。更麻烦的是，如果 timeout（进程级超时）比 retry_after 还长，PHP 进程可能卡住不退出，reserved_at 就一直不更新也不清空。

查 config/queue.php 中对应连接的 retry_after（单位秒）
查 php artisan queue:work --timeout=60 启动参数是否和配置匹配
数据库字段 retry_after 实际生效值以配置为准，不是表结构里的默认值

用 phpMyAdmin 快速识别“幽灵保留”任务

所谓“幽灵保留”，是指 reserved_at 有值，但对应 worker 进程早已退出，也没写 failed_at 或 released_at。这种任务会永远占着坑。在 phpMyAdmin 中执行这个查询：

SELECT id, job, reserved_at, available_at, created_at 
FROM jobs 
WHERE reserved_at IS NOT NULL 
  AND (failed_at IS NULL OR failed_at = '0000-00-00 00:00:00') 
  AND reserved_at <p>把 5 分钟换成你业务能接受的最大处理时长。结果里如果 <code>job</code> 字段是序列化字符串，别点开全量查看——容易卡浏览器；右键复制后本地用 <code>php artisan tinker</code> + <code>unserialize()</code> 解析更稳。</p><div class="aritcle_card flexRow artxards">
											<div class="artcardd flexRow">
												<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill7885" title="laravel-specialist"><img
														src="https://img.php.cn/upload/skill/000/000/081/179172020840450.jpg" alt="laravel-specialist" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
												<div class="aritcle_card_info flexColumn">
													<a rel="nofollow" href="/xiazai/skill7885" title="laravel-specialist" class="overflowclass">laravel-specialist</a>
													<p class="overflowclass">精通 Laravel 10+，遵循现代 PHP 实践的 Laravel 专家。擅长优雅语法、Eloquent ORM、队列系统及企业级特性...</p>
												</div>
												<a rel="nofollow" href="/xiazai/skill7885" title="laravel-specialist" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
												</a>
											</div>
										</div>

不要手动删这些记录，先确认没其他 worker 正在跑
避免用 phpMyAdmin 的“编辑”功能改 reserved_at 为 NULL——可能触发并发冲突
清理优先用命令：php artisan queue:retry all 或按 ID 重试

验证 Redis 驱动下是否因连接复用导致 `reserved_at` 滞留

如果你用的是 Redis 队列（redis 连接），reserved_at 其实不存数据库，而是存在 Redis 的 queues:default:reserved 列表里。此时 phpMyAdmin 看不到真实状态，jobs 表只是个日志备份。这时候 reserved_at 字段可能根本没更新，或者更新延迟严重。