# Django 6.0.5 documentation

# Referens till modellindex

Indexklasser underlättar skapandet av databasindex. De kan läggas till med hjälp av alternativet `Meta.indexes`. Detta dokument förklarar API-referenserna för `Index` som inkluderar index options.

Hänvisning till inbyggda index

Index definieras i `django.db.models.indexes`, men för enkelhetens skull importeras de till `django.db.models`. Standardkonventionen är att använda `from django.db import models` och hänvisa till indexen som `models.<IndexClass>`.

## alternativ för `Index`

class Index(*expressions, fields=(), name=None, db_tablespace=None, opclasses=(), condition=None, include=None)

  Skapar ett index (B-Tree) i databasen.

### `uttryck`

Index.expressions

Det positionella argumentet `*expressions` gör det möjligt att skapa funktionella index på uttryck och databasfunktioner.

Till exempel:

    Index(Lower("title").desc(), "pub_date", name="lower_title_date_idx")

skapar ett index på det gemena värdet i fältet `title` i fallande ordning och fältet `pub_date` i stigande ordning som standard.

Ett annat exempel:

    Index(F("height") * F("weight"), Round("weight"), name="calc_idx")

skapar ett index på resultatet av multiplikationen av fälten `höjd` och `vikt` och `vikt` avrundat till närmaste heltal.

`Index.name` krävs när man använder `*expressions`.

Begränsningar för Oracle

Oracle kräver att funktioner som refereras till i ett index ska markeras som `DETERMINISTIC`. Django validerar inte detta men Oracle kommer att göra ett fel. Detta innebär att funktioner som `Random()` inte accepteras.

Begränsningar på PostgreSQL

PostgreSQL kräver att funktioner och operatörer som refereras till i ett index markeras som `` IMMUTABLE``. Django validerar inte detta men PostgreSQL kommer att göra fel. Detta innebär att funktioner som `Concat()` inte accepteras.

MySQL och MariaDB

Funktionella index ignoreras med MySQL < 8.0.13 och MariaDB eftersom ingen av dem stöder dem.

### `fält`

Index.fields

En lista eller tupel med namnet på de fält som indexet önskas för.

Som standard skapas index med stigande ordning för varje kolumn. Om du vill definiera ett index med fallande ordning för en kolumn lägger du till ett bindestreck före fältets namn.

Till exempel: skulle `Index(fields=['headline', '-pub_date'])` skapa SQL med `(headline, pub_date DESC)`.

MariaDB

Indexbeställning stöds inte på MariaDB < 10.8. I så fall skapas ett fallande index som ett normalt index.

### `namn`

Index.name

Namnet på indexet. Om `name` inte anges kommer Django automatiskt att generera ett namn. För kompatibilitet med olika databaser får indexnamn inte vara längre än 30 tecken och bör inte börja med en siffra (0-9) eller understreck (_).

Partiella index i abstrakta basklasser

Du måste alltid ange ett unikt namn för ett index. Därför kan du normalt inte ange ett partiellt index på en abstrakt basklass, eftersom alternativet `Meta.indexes` ärvs av underklasser, med exakt samma värden för attributen (inklusive `name`) varje gång. För att komma runt namnkollisioner kan en del av namnet innehålla `'%(app_label)s'` och `'%(class)s'`, som ersätts av den gemena appetiketten respektive klassnamnet för den konkreta modellen. Till exempel: `Index(fields=['title'], name='%(app_label)s_%(class)s_title_index')`.

### `db_tablespace`

Index.db_tablespace

Namnet på det databas-tabellutrymme som ska användas för detta index. För index med ett enda fält skapas indexet i fältets `db_tablespace` om `db_tablespace` inte anges.

Om `Field.db_tablespace` inte anges (eller om indexet använder flera fält) skapas indexet i det tablespace som anges i `db_tablespace`-alternativet i modellens `class Meta`. Om inget av dessa tablespaces är angivet skapas indexet i samma tablespace som tabellen.

Se även

För en lista över PostgreSQL-specifika index, se `django.contrib.postgres.indexes`.

### `opklasser`

Index.opclasses

Namnen på PostgreSQL-operatörsklasserna som ska användas för detta index. Om du behöver en anpassad operatörsklass måste du tillhandahålla en för varje fält i indexet.

Till exempel: skapar `GinIndex(name='json_index', fields=['jsonfield'], opclasses=['jsonb_path_ops'])` ett ginindex på `jsonfield` med hjälp av `jsonb_path_ops`.

`` Opclasses`` ignoreras för databaser förutom PostgreSQL.

`Index.name` krävs när man använder `opclasses`.

### `villkor`

Index.condition

Om tabellen är mycket stor och dina frågor oftast riktar sig till en delmängd av rader kan det vara användbart att begränsa ett index till den delmängden. Ange ett villkor som en `Q`. Till exempel:, `condition=Q(pages__gt=400)` indexerar poster med mer än 400 sidor.

`Index.name` krävs när man använder `condition`.

Begränsningar på PostgreSQL

PostgreSQL kräver funktioner som refereras till i villkoret för att markeras som IMMUTABLE. Django validerar inte detta men PostgreSQL kommer att fel. Detta innebär att funktioner som Datumfunktioner och `Concat` inte accepteras. Om du lagrar datum i `DateTimeField`, kan jämförelse med `datetime`-objekt kräva att `tzinfo`-argumentet tillhandahålls eftersom jämförelsen annars kan resultera i en mutabel funktion på grund av den casting Django gör för lookups.

Begränsningar för SQLite

SQLite ”inför restriktioner <https://www.sqlite.org/partialindex.html>`_ för hur ett partiellt index kan konstrueras.

Oracle

Oracle har inte stöd för partiella index. Istället kan partiella index emuleras genom att använda funktionella index tillsammans med `Case`-uttryck.

MySQL och MariaDB

Argumentet `condition` ignoreras med MySQL och MariaDB eftersom ingen av dem stöder villkorliga index.

### `inkludera`

Index.include

En lista eller tupel med namnen på de fält som ska ingå i täckningsindexet som icke-nyckelkolumner. Detta gör att skanningar med enbart index kan användas för frågor som endast väljer inkluderade fält (`include`) och endast filtrerar efter indexerade fält (`fields`).

Till exempel:

    Index(name="covering_index", fields=["headline"], include=["pub_date"])

gör det möjligt att filtrera på `headline` och även välja `pub_date`, samtidigt som data endast hämtas från indexet.

Om du använder `include` får du ett mindre index än om du använder ett index med flera kolumner, men nackdelen är att kolumner som inte är nyckelkolumner inte kan användas för sortering eller filtrering.

`include` ignoreras för databaser förutom PostgreSQL.

`Index.name` krävs vid användning av `include`.

Se PostgreSQL-dokumentationen för mer information om täckande index.

Begränsningar på PostgreSQL

PostgreSQL stöder täckning av B-Tree och `GiST index`. PostgreSQL 14+ stöder också täckning av `SP-GiST-index`.