--- title: "Model index reference" version: 3.0 locale: pl source: https://docs.djangoproject.com/pl/3.0/ref/models/indexes/ canonical: https://djangodocs.dev/pl/3.0/ref/models/indexes/ --- # Model index reference Index classes ease creating database indexes. They can be added using the [`Meta.indexes`](/pl/3.0/ref/models/options/#django.db.models.Options.indexes) option. This document explains the API references of [`Index`](#django.db.models.Index) which includes the [index options](#index-options). > **Referencing built-in indexes** > > Indexes are defined in `django.db.models.indexes`, but for convenience > they’re imported into [`django.db.models`](/pl/3.0/topics/db/models/#module-django.db.models). The standard convention is > to use `from django.db import models` and refer to the indexes as > `models.`. ## `Index` options #### `class Index(fields=(), name=None, db_tablespace=None, opclasses=(), condition=None)` Creates an index (B-Tree) in the database. ### `fields` #### `Index.fields` A list or tuple of the name of the fields on which the index is desired. By default, indexes are created with an ascending order for each column. To define an index with a descending order for a column, add a hyphen before the field’s name. For example `Index(fields=['headline', '-pub_date'])` would create SQL with `(headline, pub_date DESC)`. Index ordering isn’t supported on MySQL. In that case, a descending index is created as a normal index. ### `name` #### `Index.name` The name of the index. If `name` isn’t provided Django will auto-generate a name. For compatibility with different databases, index names cannot be longer than 30 characters and shouldn’t start with a number (0-9) or underscore (\_). > **Partial indexes in abstract base classes** > > You must always specify a unique name for an index. As such, you > cannot normally specify a partial index on an abstract base class, since > the [`Meta.indexes`](/pl/3.0/ref/models/options/#django.db.models.Options.indexes) option is > inherited by subclasses, with exactly the same values for the attributes > (including `name`) each time. To work around name collisions, part of the > name may contain `'%(app_label)s'` and `'%(class)s'`, which are > replaced, respectively, by the lowercased app label and class name of the > concrete model. For example `Index(fields=['title'], > name='%(app_label)s_%(class)s_title_index')`. > **Changed in Django 3.0** > > Interpolation of `'%(app_label)s'` and `'%(class)s'` was added. ### `db_tablespace` #### `Index.db_tablespace` The name of the [database tablespace](/pl/3.0/topics/db/tablespaces/) to use for this index. For single field indexes, if `db_tablespace` isn’t provided, the index is created in the `db_tablespace` of the field. If [`Field.db_tablespace`](/pl/3.0/ref/models/fields/#django.db.models.Field.db_tablespace) isn’t specified (or if the index uses multiple fields), the index is created in tablespace specified in the [`db_tablespace`](/pl/3.0/ref/models/options/#django.db.models.Options.db_tablespace) option inside the model’s `class Meta`. If neither of those tablespaces are set, the index is created in the same tablespace as the table. > **See also** > > For a list of PostgreSQL-specific indexes, see > [`django.contrib.postgres.indexes`](/pl/3.0/ref/contrib/postgres/indexes/#module-django.contrib.postgres.indexes). ### `opclasses` #### `Index.opclasses` > **New in Django 2.2** The names of the [PostgreSQL operator classes](https://www.postgresql.org/docs/current/indexes-opclass.html) to use for this index. If you require a custom operator class, you must provide one for each field in the index. For example, `GinIndex(name='json_index', fields=['jsonfield'], opclasses=['jsonb_path_ops'])` creates a gin index on `jsonfield` using `jsonb_path_ops`. `opclasses` are ignored for databases besides PostgreSQL. [`Index.name`](#django.db.models.Index.name) is required when using `opclasses`. ### `condition` #### `Index.condition` > **New in Django 2.2** If the table is very large and your queries mostly target a subset of rows, it may be useful to restrict an index to that subset. Specify a condition as a [`Q`](/pl/3.0/ref/models/querysets/#django.db.models.Q). For example, `condition=Q(pages__gt=400)` indexes records with more than 400 pages. [`Index.name`](#django.db.models.Index.name) is required when using `condition`. > **Restrictions on PostgreSQL** > > PostgreSQL requires functions referenced in the condition to be marked as > IMMUTABLE. Django doesn’t validate this but PostgreSQL will error. This > means that functions such as [Date functions](/pl/3.0/ref/models/database-functions/#date-functions) and > [`Concat`](/pl/3.0/ref/models/database-functions/#django.db.models.functions.Concat) aren’t accepted. If you store > dates in [`DateTimeField`](/pl/3.0/ref/models/fields/#django.db.models.DateTimeField), comparison to > [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime) objects may require the `tzinfo` argument > to be provided because otherwise the comparison could result in a mutable > function due to the casting Django does for [lookups](/pl/3.0/ref/models/querysets/#field-lookups). > **Restrictions on SQLite** > > SQLite [imposes restrictions](https://www.sqlite.org/partialindex.html) > on how a partial index can be constructed. > **Oracle** > > Oracle does not support partial indexes. Instead, partial indexes can be > emulated using functional indexes. Use a [migration](/pl/3.0/topics/migrations/) to add the index using [`RunSQL`](/pl/3.0/ref/migration-operations/#django.db.migrations.operations.RunSQL). > **MySQL and MariaDB** > > The `condition` argument is ignored with MySQL and MariaDB as neither > supports conditional indexes.