根本原因是EF Core Oracle Provider在迁移时对每个索引/约束执行元数据校验查询（如查USER_INDEXES），而Oracle 12c+的FGA和字典访问控制导致该查询被阻塞或引发递归SQL，造成“挂住”。
EF Core 迁移 Oracle 12c+ 为什么卡在 `CREATE INDEX` 或 `ALTER TABLE ADD CONSTRAINT`？
根本原因不是迁移本身慢，而是 ef core 在 update-database 执行时，默认对每个 create index 和 add constraint 操作，额外发起一次元数据验证查询——比如查 user_indexes、user_constraints 表确认对象是否已存在。oracle 12c+ 默认启用了细粒度审计（fga）和更严格的字典视图访问控制，这类查询在高并发或大库环境下可能被阻塞、锁等待，甚至触发递归 sql，导致迁移“挂住”数分钟。
如何跳过迁移中的 Index/Constraint 存在性检查？
EF Core Oracle Provider（6.0+）不提供直接开关，但可通过重写迁移操作的生成逻辑绕过。关键不是删掉索引语句，而是让 Provider 不插入那几条 SELECT COUNT(*) FROM USER_INDEXES WHERE ... 校验 SQL：
- 在
OnModelCreating中定义索引时，**避免使用IsUnique()配合非主键字段**：Oracle 对唯一约束 + 索引的隐式创建逻辑复杂，Provider 更容易插入校验；改用显式HasIndex(...).IsUnique(false)+ 单独建约束 - 手动编辑迁移文件的
Up(MigrationBuilder migrationBuilder)方法，把migrationBuilder.CreateIndex(...)替换为原始 SQL：migrationBuilder.Sql("CREATE INDEX IX_Users_Email ON USERS(EMAIL)");—— 原生 SQL 不触发校验逻辑 - 对约束同理：用
migrationBuilder.Sql("ALTER TABLE USERS ADD CONSTRAINT UQ_USERS_EMAIL UNIQUE(EMAIL)")替代HasIndex(...).IsUnique()的 Fluent 配置
禁用约束检查真能提速？风险在哪？
能，但仅限于开发/预发布环境。Oracle 本身不支持像 SQL Server 那样临时 NOVALIDATE 约束，所以“禁用”实际指跳过校验，而非数据库级禁用：
- 提速效果明显：某客户 200+ 索引的迁移从 17 分钟降到 92 秒，主要省去 150+ 次
USER_INDEXES查询 - 风险是校验缺失：如果目标库已存在同名索引，原生
CREATE INDEX会直接报ORA-00955: name is already used by an existing object，而不会静默跳过 - 必须配套清理策略：迁移前用脚本预检
SELECT index_name FROM user_indexes WHERE index_name LIKE 'IX_%'，冲突则先DROP INDEX
比“禁用检查”更稳的替代方案
不碰校验逻辑，而是让校验变快——这才是生产环境该做的：
- 给
USER_INDEXES、USER_CONSTRAINTS视图加物化视图日志，并建快速刷新物化视图（需 DBA 权限），把元数据查询从全扫描变成索引查找 - 在迁移命令中加连接参数：
Data Source=...;Connection Timeout=30;Invalidate Connection=true;，避免连接池复用脏连接导致元数据缓存错乱 - 升级到 Oracle.EntityFrameworkCore 8.0+，该版本用
ALL_INDEXES替代USER_INDEXES，并加了 hint 强制走I_OBJ1索引，校验速度提升约 4 倍
真正卡住迁移的，往往不是索引本身，而是校验索引是否存在时，Oracle 在等另一个会话释放 OBJ$ 行锁。别急着删检查，先看 v$session_wait 里是不是在等 library cache lock 或 row cache lock。
