删除 failed_jobs 表数据不等于重试任务，必须用 php artisan queue:retry 命令才能真正重放失败任务；删表仅清除记录，不会触发重试，且重试依赖表中现存记录。
直接删 failed_jobs 表数据不等于重试任务
清空 failed_jobs 表只是把失败记录删了，laravel 不会因此自动重播这些任务。队列本身已跳过它们，除非你手动触发重试逻辑，否则它们永远停留在“已失败”状态，不会重新进队列。
常见错误现象：DELETE FROM failed_jobs 后发现任务没重跑，日志里也没新执行痕迹；或者用 php artisan queue:retry all 报错说“no failed jobs found”，但业务上明明该重试。
- 必须先确保任务类的
$tries或$maxExceptions没被设为 0，否则重试时直接跳过 - 如果任务里用了
DB::transaction()或外部锁机制，失败后残留状态可能让重试也立刻失败 -
failed_jobs表里uuid字段是唯一标识，删表后重试要用新 UUID，旧任务无法“续上”
用 queue:retry 命令才是真正重试动作
删除记录只是清理，queue:retry 才是把失败任务捞出来、重置尝试次数、重新推入队列的核心操作。它依赖 failed_jobs 表当前存在的记录 —— 所以不能先删再 retry。
使用场景：线上排查完失败原因（比如修复了 Redis 连接配置、补全了环境变量），需要批量重放历史失败任务。
- 重试单个任务：
php artisan queue:retry <code>id（id是failed_jobs.id） - 重试全部：
php artisan queue:retry all（注意：不是failed_jobs表空了才跑这个） - 重试指定范围：
php artisan queue:retry --since="2024-05-01"（需 Laravel 10.29+） - 加
--force可绕过维护模式检查，但生产环境慎用
phpMyAdmin 里操作要分两步：查 + 清，不能只删
在 phpMyAdmin 中直接操作数据库，容易误删或漏步骤。关键不是“怎么删”，而是“删之前有没有确认过是否真要重试”。很多情况其实该先看 failed_jobs.exception 内容，而不是急着清。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 先在 phpMyAdmin 打开
failed_jobs表，点“浏览”，勾选几条，点“复制”看完整exception字段 —— 很多失败是临时网络问题，重试即可；有些是代码 bug，删了也没用 - 如果确认要清，用 SQL 标签页执行：
TRUNCATE TABLE failed_jobs（比DELETE快，且重置自增 ID） - 但删完必须立刻跑
php artisan queue:retry all，否则等于白干；如果队列没在运行，还要补一句php artisan queue:work或检查 Supervisor 状态 - 别用 phpMyAdmin 的“清空表”按钮（带警告图标那个），它有时生成的是带 WHERE 的 DELETE，慢且不彻底
重试失败任务前务必检查队列驱动和任务反序列化兼容性
如果 Laravel 升级过（比如从 9.x 到 10.x），或改过任务类的命名空间、构造参数，旧的 failed_jobs.payload 可能无法反序列化，导致 queue:retry 执行时报 Class not found 或 unserialize(): Error at offset。
这种情况下硬删 + retry 会失败，甚至卡住命令行。
- 先在本地用相同版本 Laravel 尝试
unserialize($payload)看是否报错（$payload取自failed_jobs.payload字段） - 如果任务类已重命名，可以用
php artisan queue:flush彻底清空所有队列（包括 pending 和 delayed），但这是最后手段 - 更稳妥的做法：写一个一次性 Artisan 命令，读取
failed_jobs，按新结构重建任务实例，再dispatch()新任务
真正麻烦的从来不是删记录，而是 payload 里藏着过期的闭包、未加载的类、或序列化时用的 PHP 版本和现在不一致 —— 这些在 phpMyAdmin 里完全看不见。
