MySQL数据库运行EF迁移报错：空间/全文/哈希索引使用不当

我帮你梳理了这个问题的来龙去脉和可行的解决办法，具体如下：

问题详情 #

你在全新安装的MySQL 8.0.11 Community上运行EF 6.2.0迁移时，遇到了索引创建失败的错误：

Incorrect usage of spatial/fulltext/hash index and explicit index order

触发错误的是创建AuditLog表时的.Index(t => t.Who_Id)调用，通过Update-Database -verbose追踪到EF生成了有问题的SQL：

CREATE index `IX_Who_Id` on `AuditLog` (`Who_Id` DESC) using HASH

之前这个迁移在SQL Server和3年前的旧版MySQL上都能正常运行，升级到MySQL 8.0后先是遇到密码认证错误，通过更新NuGet包或强制使用旧密码解决；后来更新到最新MySQL NuGet包又碰到API兼容问题，最终降级到MySql.Data/MySql.Data.Entity 6.10.7后连接恢复正常，但索引生成的问题依然存在。

问题根源 #

MySQL 8.0对HASH索引有严格限制：HASH索引不支持指定排序方向（DESC/ASC），但EF的MySQL Provider错误地同时生成了DESC排序和HASH索引类型，这就违反了MySQL的语法规则。旧版MySQL对这种错误的兼容性更高，所以没触发报错。

可行解决方案 #

1. 修改EF迁移代码，指定兼容的索引类型 #

直接在迁移文件里修改Index方法，明确指定使用BTREE索引（MySQL支持排序的默认索引类型）：

.Index(t => t.Who_Id, null, null, "BTREE");

或者去掉默认的排序规则，让Provider生成正确的SQL：

.Index(t => t.Who_Id, name: "IX_Who_Id");

修改后生成的SQL会变成：

CREATE index `IX_Who_Id` on `AuditLog` (`Who_Id`) using BTREE

这样就能正常执行迁移了。

2. 临时降级到MySQL 5.x版本 #

如果不想修改代码，可以暂时把数据库降级到MySQL 5.x系列，这个版本对EF生成的有问题的索引SQL兼容性更好，无需改动代码就能顺利完成迁移。

3. 手动执行迁移SQL #

如果已经生成了迁移脚本，可以直接手动修改SQL语句：要么去掉DESC，要么把using HASH替换成using BTREE，然后直接在MySQL客户端执行修改后的脚本，跳过EF的自动生成逻辑。

4. 等待官方NuGet包更新 #

这个问题本质是MySql.Data.Entity组件的bug，后续官方更新应该会修复MySQL 8.0下的索引生成逻辑，你可以关注NuGet包的更新动态，等新版本发布后再尝试升级测试。

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