EF6 Code-First迁移MySQL时触发StackOverflowException问题求助

我来帮你梳理下问题所在和解决办法：

问题根源分析 #

你遇到的StackOverflowException本质是EF模型与数据库结构的元数据完全不匹配，加上手动修改数据库后破坏了EF迁移的状态一致性：

1. 你先跳过EF的迁移机制，手动通过Sql("ALTER TABLE table MODIFY COLUMN ID BIGINT NOT NULL AUTO_INCREMENT")把数据库列改成了BIGINT，但此时模型里的ID还是int类型——EF的内部元数据仍然认为模型和数据库应该是int匹配int，这时候已经埋下了不匹配的隐患。
2. 之后你把模型ID改成long，但EF的迁移历史记录（__MigrationHistory表）里并没有记录这次“模型从int改long”的操作，当EF执行CompatibleWithModel或者Update-Database时，会尝试对比当前模型和数据库的元数据，这种不一致导致EF在内部逻辑中陷入循环递归，最终触发栈溢出。

解决当前异常的步骤 #

步骤1：对齐模型与数据库的元数据一致性 #

首先要让EF的迁移历史和实际数据库状态同步：

1. 确认你的模型ID已经修改为[Key] public long ID { get; set; }（已经改好的话跳过这步）。
2. 在Package Manager Console中执行：

   Add-Migration FixIdTypeMismatch -IgnoreChanges
   

   这个命令会生成一个空的迁移文件（因为加了-IgnoreChanges参数），核心作用是把当前的模型状态快照写入迁移历史表，让EF认为“当前模型就是数据库应该匹配的状态”。
3. 接着执行更新数据库：

   Update-Database -Verbose
   

   这一步不会修改数据库结构（迁移是空的），但会更新__MigrationHistory表，让EF的元数据和实际数据库彻底对齐。

步骤2：验证修复效果 #

现在再运行你的兼容性检查代码if (!Database.CompatibleWithModel(false)) { Database.Initialize(true); }，应该不会再抛出StackOverflowException了。如果还有问题，可以尝试清理项目的bin/obj目录后重启应用，清除EF的本地缓存。

正确的迁移创建方式（你的疑问解答） #

正确的流程一定是先修改模型，再调用Add-Migration生成迁移文件，最后执行Update-Database，而不是手动修改数据库：

1. 修改模型中的ID类型从int到long。
2. 在Package Manager Console执行：

   Add-Migration ChangeIdColumnToBigInt
   

   EF会自动生成迁移文件，其中Up()方法会包含适配MySQL的列类型修改代码（类似你手动写的ALTER TABLE语句）。
3. 执行：

   Update-Database -Verbose
   

   让EF自动同步数据库结构，同时更新迁移历史记录，确保模型、迁移历史、数据库三者完全一致。

为什么不建议手动写Sql修改数据库？ #

手动修改数据库会绕过EF的迁移管理机制，导致__MigrationHistory中的模型快照和实际数据库结构脱节，EF无法正确跟踪状态，很容易出现各种元数据不一致的问题（比如这次的栈溢出）。只有在EF自动生成的迁移代码无法满足复杂自定义操作需求时，才建议在自动生成的迁移文件中补充Sql()语句。

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