laravel需先执行php artisan queue:failed-table和php artisan migrate创建failed_jobs表，否则无法查询；表结构因版本差异主键类型不同，字段需匹配，且exception和payload需用sql或工具完整解析，重试应优先使用queue:retry命令而非手动修改字段。
查 failed_jobs 表前先确认表结构是否完整
laravel 默认用 failed_jobs 表存失败任务，但这个表不是自动创建的——它依赖你运行过 php artisan queue:failed-table 和 php artisan migrate。如果 phpmyadmin 里找不到这张表，别急着翻日志，先检查迁移是否执行成功：select * from migrations where migration like '%failed_jobs%';。没结果？说明表根本没建。另外注意 laravel 9+ 默认使用 uuid 为主键，字段是 id（类型 char(36)），不是 bigint；旧版本可能是 bigincrements。字段名对不上、类型不匹配，会导致 queue:retry 或手动插入时出错。
看 exception 字段得展开 JSON 内容
phpMyAdmin 默认只显示 exception 字段前 50 个字符，而真实异常堆栈往往藏在后面。点击对应行右侧的「编辑」按钮，或者直接在 SQL 标签页执行：SELECT id, job, exception FROM failed_jobs WHERE id = 123;，再复制 exception 值到本地 IDE 或 JSON 格式化工具里解析。常见陷阱：异常里包含换行和单引号，直接在 phpMyAdmin 的「浏览」视图里点「编辑」可能被截断或转义错；更稳的方式是用「导出」→「自定义」→ 取消勾选「截断长文本」，导出为 CSV 或 JSON 再查看。
用 payload 字段反推任务类和参数
payload 是 JSON 字符串，里面藏着真正执行的任务类名、方法、参数和 attempts 计数。不要靠肉眼扫描，执行这条 SQL 快速定位：SELECT id, JSON_UNQUOTE(JSON_EXTRACT(payload, '$.job')) AS job_class, JSON_EXTRACT(payload, '$.data.command') AS command FROM failed_jobs WHERE id = 123;。如果返回空，说明是 Laravel 8 之前的老格式，payload 是序列化的 PHP 字符串（serialize()），此时 phpMyAdmin 无法直接解析，得用 PHP 手动 unserialize()，或者改用 artisan tinker 加载该条记录再 dump。注意：Laravel 9+ 默认用 json 驱动，但如果你在 config/queue.php 里显式设了 'connection' => 'database' 且没配 'driver' => 'database' 的序列化方式，也可能混用格式。
重试前先清空无效的 attempts 或 reserved_at
直接点 phpMyAdmin 里的「插入」或「编辑」改 attempts 值并不安全。Laravel 重试逻辑依赖 attempts、available_at、reserved_at 三者配合：比如把 attempts 改成 0 但没清 reserved_at，下次 worker 拉取时会跳过（认为还在保留中）；又或者 available_at 是未来时间戳，任务永远不触发。稳妥做法是用命令行：php artisan queue:retry 123，它会自动重置所有相关字段。如果必须手动操作，至少同时执行：UPDATE failed_jobs SET attempts = 0, reserved_at = NULL, available_at = UNIX_TIMESTAMP() WHERE id = 123;。另外，failed_jobs 表本身不参与队列消费，只做归档，所以删掉记录不会影响当前队列运行，但别误删还没分析完的条目。
排查这事，关键不在“怎么看到”，而在“看到之后信不信”。payload 和 exception 里那些缩写、省略号、转义字符，最容易让人误判错误源头。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
