---
title: "Referens till modellindex"
version: 6.0
locale: sv
source: https://docs.djangoproject.com/sv/6.0/ref/models/indexes/
canonical: https://djangodocs.dev/sv/6.0/ref/models/indexes/
---
# Referens till modellindex

Indexklasser underlättar skapandet av databasindex. De kan läggas till med hjälp av alternativet [`Meta.indexes`](/sv/6.0/ref/models/options/#django.db.models.Options.indexes). Detta dokument förklarar API-referenserna för [`Index`](#django.db.models.Index) som inkluderar [index options](#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`](/sv/6.0/topics/db/models/#module-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`](#django.db.models.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()`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.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()`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.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`](/sv/6.0/ref/models/options/#django.db.models.Options.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](/sv/6.0/topics/db/tablespaces/) 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`](/sv/6.0/ref/models/fields/#django.db.models.Field.db_tablespace) inte anges (eller om indexet använder flera fält) skapas indexet i det tablespace som anges i [`db_tablespace`](/sv/6.0/ref/models/options/#django.db.models.Options.db_tablespace)-alternativet i modellens `class Meta`. Om inget av dessa tablespaces är angivet skapas indexet i samma tablespace som tabellen.

> **See also**
>
> För en lista över PostgreSQL-specifika index, se [`django.contrib.postgres.indexes`](/sv/6.0/ref/contrib/postgres/indexes/#module-django.contrib.postgres.indexes).

### `opklasser`

#### `Index.opclasses`

Namnen på [PostgreSQL-operatörsklasserna](https://www.postgresql.org/docs/current/indexes-opclass.html) 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`](#django.db.models.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`](/sv/6.0/ref/models/querysets/#django.db.models.Q). Till exempel:, `condition=Q(pages__gt=400)` indexerar poster med mer än 400 sidor.

[`Index.name`](#django.db.models.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](/sv/6.0/ref/models/database-functions/#date-functions) och [`Concat`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.Concat) inte accepteras. Om du lagrar datum i [`DateTimeField`](/sv/6.0/ref/models/fields/#django.db.models.DateTimeField), kan jämförelse med [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.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](/sv/6.0/ref/models/querysets/#field-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`](/sv/6.0/ref/models/conditional-expressions/#django.db.models.expressions.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`](#django.db.models.Index.include)) och endast filtrerar efter indexerade fält ([`fields`](#django.db.models.Index.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`](#django.db.models.Index.name) krävs vid användning av `include`.

Se PostgreSQL-dokumentationen för mer information om [täckande index](https://www.postgresql.org/docs/current/indexes-index-only-scans.html).

> **Begränsningar på PostgreSQL**
>
> PostgreSQL stöder täckning av B-Tree och [`GiST index`](/sv/6.0/ref/contrib/postgres/indexes/#django.contrib.postgres.indexes.GistIndex). PostgreSQL 14+ stöder också täckning av [`SP-GiST-index`](/sv/6.0/ref/contrib/postgres/indexes/#django.contrib.postgres.indexes.SpGistIndex).