Laravel 5.4数据库迁移失败：仅生成users表，其余表未创建

这种情况我之前处理过几次，结合你提到的报错“cannot drop table register_users and password_resets”和实际表未创建的现象，咱们按以下步骤逐一排查：

1. 先检查迁移文件的核心逻辑 #

报错提示要删除不存在的表，大概率是你的迁移文件写反了操作——本来要创建表，结果写成了删除。

• 打开register_users和password_resets对应的迁移文件，确认顶部的up方法里是Schema::create()而不是Schema::drop()或Schema::dropIfExists()。
• 错误示例（会触发删除不存在表的报错）：

  public function up()
  {
      Schema::dropIfExists('register_users');
  }
  

• 正确的创建写法：

  public function up()
  {
      Schema::create('register_users', function (Blueprint $table) {
          $table->increments('id');
          // 你的其他字段定义
          $table->timestamps();
      });
  }
  

2. 检查Laravel迁移历史表 #

Laravel的migrations表会记录所有已执行的迁移任务，可能这两个迁移已经被标记为“已完成”，但实际表并未创建（比如之前迁移失败后历史记录没更新）：

• 执行命令查看迁移状态：

  php artisan migrate:status
  

• 如果register_users和password_resets对应的迁移显示为Ran，但数据库里没有这两张表，就需要手动登录数据库，删除migrations表中这两条记录，然后重新执行迁移：

  DELETE FROM migrations WHERE migration LIKE '%register_users%' OR migration LIKE '%password_resets%';
  

3. 验证数据库权限与表的实际状态 #

• 先登录你的数据库（比如用MySQL命令行、phpMyAdmin或其他可视化工具），执行以下SQL确认表是否真的不存在：

  SHOW TABLES LIKE 'register_users';
  SHOW TABLES LIKE 'password_resets';
  

• 如果表确实不存在，检查Laravel配置的数据库用户是否拥有CREATE、DROP表的权限——没有这些权限的话，迁移会静默失败或抛出权限错误。
• 如果表存在但你看不到，可能是数据库用户没有SELECT权限，需要给用户分配对应权限。

4. 查看详细迁移日志定位问题 #

执行迁移时加上-v参数，能看到每一步执行的SQL语句，更容易找到中断点：

php artisan migrate -v

比如，如果迁移先执行了删除表的操作（而表不存在），会直接抛出错误中断整个流程，导致后面的创建表代码根本没机会执行。

5. 特殊情况：password_resets表的默认迁移 #

Laravel默认的Auth脚手架会自动生成password_resets的迁移文件，如果你手动重复创建了这个表的迁移，可能会导致冲突。检查你的迁移目录里是否有两个关于password_resets的迁移文件，是的话删除多余的那个。

按照上面的步骤排查，基本就能解决问题了。

内容的提问来源于stack exchange，提问作者Realalun