phpMyAdmin 虽然不能直接执行 php artisan migrate，但在排查 Laravel 12 迁移失败问题时非常实用，通常可以快速锁定三类常见原因：数据表已存在、外键约束冲突，以及字段定义与数据库当前实际状态不一致。排查时应重点检查 migrations 表记录、外键是否启用，以及 information_schema.COLUMNS 中字段信息是否存在偏差。
当 Laravel 12 迁移失败时，phpMyAdmin 无法直接运行 php artisan migrate 命令，但非常适合用来快速定位三类核心故障：表已经存在、外键约束异常、字段结构与数据库实际状态不匹配。
看 failed_jobs 表有没有残留的失败记录
Laravel 12 默认支持队列失败重试机制，但数据库迁移本身并不通过队列执行，因此这个表和迁移失败通常没有直接关系。真正需要重点查看的是 migrations 表。进入 phpMyAdmin 后，选择目标数据库，找到 migrations 表，并按 batch 倒序排序，重点检查最后几条记录：
- 如果某条记录的
batch值明显高于当前实际预期（例如你只执行到 batch 3，却出现 batch 5），通常说明迁移记录曾被手动写入，或迁移过程发生过异常中断 - 检查
migration字段内容是否与本地database/migrations/目录中的文件名完全一致，包括时间戳前缀，Laravel 会严格按该字符串进行匹配 - 如果发现相同的
migration名称出现在不同的batch中，往往表示该迁移曾经部分执行后回滚失败，这时需要先手动清理相关表结构，再删除这条异常记录
用 SQL 查询验证外键约束是否被禁用
Laravel 12 在 Schema::create() 中通常会正常创建外键（当 DB::getDoctrineSchemaManager()->getDatabasePlatform()->supportsForeignKeyConstraints() 返回 true 时），但某些托管环境，尤其是部分共享主机，可能会强制关闭外键检查。你可以在 phpMyAdmin 的“SQL”标签页中执行下面这条语句：
SELECT @@FOREIGN_KEY_CHECKS;
如果返回结果为 0，说明当前数据库外键检查已被禁用。这种情况下，foreignId() 或 foreignIdFor() 定义的关联字段可能无法真正创建外键约束，表面上迁移似乎成功，但实际缺少关键的关联关系。修复时不要从 phpMyAdmin 设置入手，而应优先确认 MySQL 配置中的 foreign_key_checks=ON，或者在迁移文件中明确补充如下外键定义：
Schema::table('posts', function (Blueprint $table) {
$table->foreignId('user_id')->constrained()->onUpdate('cascade')->onDelete('cascade');
});
需要注意的是，Laravel 12 不会再自动包裹 DB::statement('SET FOREIGN_KEY_CHECKS = 1') 这类语句，因此外键能否生效，最终仍取决于底层 MySQL 的实际状态。
对比 information_schema.COLUMNS 查字段类型偏差
这类问题常见于旧项目升级到 Laravel 12 之后，迁移时容易报错，例如 SQLSTATE[HY000]: General error: 1060 Duplicate column name 'xxx'，或者 SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'xxx'。遇到这种错误时，不建议第一时间反复重跑迁移，而应先在 phpMyAdmin 中执行以下 SQL，核对当前表字段状态：
SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db_name' AND TABLE_NAME = 'users';
然后将查询结果与迁移文件中的 Schema::create('users', ...) 定义逐项对照：
DATA_TYPE如果是varchar，而代码写的是$table->string('name', 255)，通常属于正常情况；但如果代码写的是$table->text('name')，数据库里却仍显示为varchar(191)，就说明之前的迁移可能执行到一半被中断COLUMN_DEFAULT为NULL，而代码中使用了$table->timestamp('email_verified_at')->nullable()，这是正常的；但如果代码写成$table->timestamp('email_verified_at')->useCurrent()，查询结果却仍为NULL，则可能表示 MySQL 版本低于 5.6.5，不支持TIMESTAMP DEFAULT CURRENT_TIMESTAMP相关语法- 还要特别留意 Laravel 12 对
json字段的处理：只有 MySQL 5.7 及以上版本才原生支持 JSON 类型，否则可能退化为TEXT；如果迁移检测到数据库不支持，通常会直接报错，此时可在config/database.php的mysql配置中临时添加'strict' => false进行调试（仅建议用于排查）
很多时候，真正导致 Laravel 迁移卡住的，并不是迁移语法本身，而是 phpMyAdmin 中展示的数据库结构与 Laravel 认为的“当前状态”之间存在隐藏差异。比如某个字段曾被其他脚本直接执行过 ALTER，或者迁移文件里使用了 ->after('xxx')，但目标列名实际拼写有误甚至带空格。实际排查时，先看 migrations 表的最后一条记录，再核对对应数据表的 information_schema 信息，通常比反复执行 php artisan migrate:fresh 更高效，也更适合精准定位 Laravel 12 数据库迁移失败原因。
