Удаляет ли Entity Framework Core HasAlternateKey индекс на FK?

Question

У меня есть приложение ASP.Net Core, которое использует Entity Framework Core ORM и две сущности в БД MS-SQL, которые имеют отношение один ко многим - Company и Trigger. Таким образом, компания может иметь несколько триггеров. Они отображаются так:

modelBuilder.Entity<OnsiteCampaignTrigger>()
                .HasOne(x => x.Campaign)
                .WithMany(x => x.Triggers)
                .HasForeignKey(x => x.CampaignId)
                .OnDelete(DeleteBehavior.Cascade);

Каждый триггер имеет тип, и я хочу иметь возможность создавать только один триггер каждого типа для одной компании. Поэтому я хочу сделать комбинацию столбцов Type и CompanyId уникальной для таблицы триггеров. Я решил использовать конфигурацию HasAlternateKey следующим образом:

modelBuilder.Entity<Trigger>()
                .HasAlternateKey(x => new { x.CampaignId, x.Type });

Но в EF-миграции я получил это:

migrationBuilder.DropIndex(
                name: "IX_Triggers_CampaignId",
                table: "Triggers");

migrationBuilder.AddUniqueConstraint(
                name: "AK_Triggers_CampaignId_Type",
                table: "Triggers",
                columns: new[] { "CampaignId", "Type" });

Похоже, он сбросил мой индекс по внешнему ключу CampaignId! Приведет ли это к снижению производительности?

Answer 1

Уникальный индекс, созданный для AK_Triggers_CampaignId_Type, будет делать все, что будет делать индекс IX_Triggers_CampaignId (поскольку все ключевые столбцы в IX_Triggers_CampaignId включены в том же порядке в начале ключевых столбцовAK_Triggers_CampaignId_Type), но с немного большим размером.Я бы сказал, что разница в производительности из-за немного большего размера индекса незначительна, поэтому не стоит тратить пространство на другой индекс с почти такими же данными (потому что это приведет к небольшому снижению производительности для операций вставки / обновления / удаления).).