Indexek

Az indexek sok adattárban gyakori fogalomnak számítanak. Bár az adattárban való megvalósításuk eltérő lehet, az oszlopok (vagy oszlopok) alapján végzett keresések hatékonyabbá teszik őket. A megfelelő indexhasználatról további információt a teljesítménydokumentáció indexek szakaszában talál.

Egy oszlopon az alábbi módon adhat meg indexet:

[Index(nameof(Url))]
public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }
}

Megjegyzés

Konvenció szerint egy index jön létre minden olyan tulajdonságban (vagy tulajdonságkészletben), amelyet idegen kulcsként használnak.

Összetett index

Az indexek egynél több oszlopra is kiterjedhetnek:

[Index(nameof(FirstName), nameof(LastName))]
public class Person
{
    public int PersonId { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Az több oszlopot lefedő indexek, más néven összetett indexek, felgyorsítják a lekérdezéseket, amelyek az indexoszlopokra szűrnek, valamint azokat is, amelyek az index által lefedett első oszlopokra szűrnek. További információért tekintse meg a teljesítmény-dokumentációt.

Összetett típusú tulajdonságok indexei

Az EF Core 11.0-tól kezdve az indexek összetett típusokba ágyazott skaláris tulajdonságokat használhatnak:

modelBuilder.Entity<Customer>()
    .HasIndex(c => c.Address.PostalCode);

Az összetett indexek kombinálhatják a normál entitástulajdonságokat és az összetett típustulajdonságokat:

modelBuilder.Entity<Customer>()
    .HasIndex(c => new { c.Region, c.Address.PostalCode });

Ugyanazokat az elérési utakat lehet név szerint megadni:

modelBuilder.Entity<Customer>()
    .HasIndex("Address.PostalCode");

A JSON-oszlopokra leképezett összetett típusok esetében a szolgáltatók a JSON-dokumentumban lévő indexelési útvonalakat is támogathatják:

modelBuilder.Entity<Customer>()
    .ComplexProperty(c => c.Address, b => b.ToJson());

modelBuilder.Entity<Customer>()
    .HasIndex("Address.PostalCode");

Az összetett gyűjtemények indexei a gyűjtemény elérési útjának szintaxisát használják. [] az összes elemet, míg [0]a , [1]és így tovább egy adott elemet jelöl:

modelBuilder.Entity<Order>()
    .ComplexCollection(o => o.Items, b => b.ToJson());

modelBuilder.Entity<Order>()
    .HasIndex("Items[].Sku");

Ugyanez az index egy lambda kifejezéssel konfigurálható a következő használatával Select:

modelBuilder.Entity<Order>()
    .HasIndex(o => o.Items.Select(i => i.Sku));

A JSON-elérésiút-indexek támogatása az adatbázis-szolgáltatótól függ. A SQL Server szolgáltató például olyan SQL Server JSON-indexeket hoz létre, amelyek támogatottak, míg a Azure Cosmos DB szolgáltató a konfigurált elérési utakat bocsátja ki a tárolóindexelési szabályzatba.

Index egyedisége

Alapértelmezés szerint az indexek nem egyediek: több sor is rendelkezhet ugyanazokkal az érték(ek)sel az index oszlopkészletéhez. Az indexeket az alábbiak szerint teheti egyedivé:

[Index(nameof(Url), IsUnique = true)]
public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }
}

Ha egynél több entitást próbál beszúrni az index oszlopkészletébe azonos értékekkel, kivétel jön létre.

Index rendezési sorrendje

A legtöbb adatbázisban az index által lefedett minden oszlop növekvő vagy csökkenő lehet. A csak egy oszlopot lefedő indexek esetében ez általában nem számít: az adatbázis szükség szerint fordított sorrendben haladhat át az indexen. Összetett indexek esetén azonban a rendezés kulcsfontosságú lehet a jó teljesítmény szempontjából, és jelentheti a különbséget aközött, hogy egy indexet használ-e a lekérdezés vagy sem. Az indexoszlopok rendezési sorrendjének általában meg kell egyeznie a lekérdezés ORDER BY záradékában megadott sorrendekkel.

Az index rendezési sorrendje alapértelmezés szerint növekvő. Az összes oszlop csökkenő sorrendet állíthat be az alábbiak szerint:

[Index(nameof(Url), nameof(Rating), AllDescending = true)]
public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }
    public int Rating { get; set; }
}

A rendezési sorrendet oszloponként is megadhatja az alábbiak szerint:

[Index(nameof(Url), nameof(Rating), IsDescending = new[] { false, true })]
public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }
    public int Rating { get; set; }
}

Indexelnevezés és több index

Konvenció szerint a relációs adatbázisban létrehozott indexek neve IX_<type name>_<property name>. Összetett indexek esetén <property name> a tulajdonságnevek aláhúzásjelekkel tagolt listájává válik.

Az adatbázisban létrehozott index nevét beállíthatja:

[Index(nameof(Url), Name = "Index_Url")]
public class Blog
{
    public int BlogId { get; set; }
    public string Url { get; set; }
}

Vegye figyelembe, hogy ha több alkalommal is meghívja HasIndex ugyanazon tulajdonságkészleten, az továbbra is egyetlen indexet konfigurál ahelyett, hogy újat hoz létre:

modelBuilder.Entity<Person>()
    .HasIndex(p => new { p.FirstName, p.LastName })
    .HasDatabaseName("IX_Names_Ascending");

modelBuilder.Entity<Person>()
    .HasIndex(p => new { p.FirstName, p.LastName })
    .HasDatabaseName("IX_Names_Descending")
    .IsDescending();

Mivel a második HasIndex hívás felülbírálja az elsőt, ez csak egyetlen, csökkenő indexet hoz létre. Ez hasznos lehet egy konvenció által létrehozott index további konfigurálásához.

Ha több indexet szeretne létrehozni ugyanazon tulajdonságkészleten belül, adjon nevet a HasIndex, amely az EF-modellben lévő index azonosítására és az ugyanazon tulajdonságokon belüli más indexektől való megkülönböztetésére szolgál:

modelBuilder.Entity<Person>()
    .HasIndex(p => new { p.FirstName, p.LastName }, "IX_Names_Ascending");

modelBuilder.Entity<Person>()
    .HasIndex(p => new { p.FirstName, p.LastName }, "IX_Names_Descending")
    .IsDescending();

Vegye figyelembe, hogy ez a név is alapértelmezettként használatos az adatbázisnévhez, ezért nem szükséges explicit módon meghívni HasDatabaseName.

Indexszűrő

Egyes relációs adatbázisok lehetővé teszik szűrt vagy részleges index megadását. Ez lehetővé teszi, hogy az oszlop értékeinek csak egy részhalmazát indexelje, csökkentve az index méretét, és javítja a teljesítményt és a lemezterület-használatot is. Az SQL Server szűrt indexeivel kapcsolatos további információkért tekintse meg a dokumentációt.

A Fluent API-val megadhat egy index szűrőt, amely SQL-kifejezésként van megadva:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .HasIndex(b => b.Url)
        .HasFilter("[Url] IS NOT NULL");
}

Az SQL Server-szolgáltató használatakor az EF egy 'IS NOT NULL' szűrőt ad hozzá az egyedi index részét képező összes null értékű oszlophoz. A konvenció felülbírálásához megadhat egy null értéket.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .HasIndex(b => b.Url)
        .IsUnique()
        .HasFilter(null);
}

Belefoglalt oszlopok

Egyes relációs adatbázisok lehetővé teszik olyan oszlopok konfigurálását, amelyek bekerülnek az indexbe, de nem részei annak "kulcsának". Ez jelentősen javíthatja a lekérdezés teljesítményét, ha a lekérdezés összes oszlopa kulcs- vagy nem kulcsoszlopként szerepel az indexben, mivel magát a táblát nem kell elérni. Az SQL Server oszlopokkal kapcsolatos további információkért tekintse meg a dokumentációt.

A következő példában a Url oszlop az indexkulcs része, így az adott oszlopra szűrt lekérdezések használhatják az indexet. Emellett azonban a csak a Title és PublishedOn oszlopokat elérő lekérdezések nem fognak hozzáférni a táblához, és hatékonyabban fognak futni:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Post>()
        .HasIndex(p => p.Url)
        .IncludeProperties(
            p => new { p.Title, p.PublishedOn });
}

Az EF Core 11.0-tól kezdve SQL Server belefoglalt oszlopok összetett típusokba ágyazott skaláris tulajdonságokra is hivatkozhatnak:

modelBuilder.Entity<Customer>()
    .HasIndex(c => c.Name)
    .IncludeProperties(c => c.Address.City);

Korlátozások ellenőrzése

Az ellenőrzési korlátozások egy szabványos relációs funkció, amely lehetővé teszi egy olyan feltétel megadását, amely a tábla összes sorához meg kell tartania; a kényszert sértő adatok beszúrására vagy módosítására tett kísérletek sikertelenek lesznek. Az ellenőrzési kényszerek hasonlóak a nem null értékű kényszerekhez (amelyek tiltják a null értékeket egy oszlopban) vagy egyedi kényszerekhez (amelyek tiltják az ismétlődéseket), de lehetővé teszik tetszőleges SQL-kifejezés definiálását.

A Fluent API használatával megadhat egy ellenőrzési kényszert egy táblán, amely SQL-kifejezésként van megadva:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder
        .Entity<Product>()
        .ToTable(b => b.HasCheckConstraint("CK_Prices", "[Price] > [DiscountedPrice]"));
}

Ugyanazon a táblán több ellenőrzési korlátozás is definiálható, mindegyiknek saját neve van.

Megjegyzés: néhány gyakori ellenőrzési korlátozás konfigurálható az EFCore.CheckConstraints közösségi csomagon keresztül.

  • Last updated on