
# Indexen

`DocStore`-indexen worden naast de collectie opgeslagen onder `.storh/indexes`. Het zijn gewone bestanden die volledig uit de records zijn afgeleid en op elk moment opnieuw kunnen worden opgebouwd. Definieer ze fluently of via een [schema](https://storh.inline0.dev/nl/docs/schema):

```php
$docs->indexes()
    ->field('slug')->unique()
    ->field('kind')
    ->field('publishedAt')->range()
    ->sync();
```

Indextypen:

- gelijkheidsindexen voor velden zoals `kind` of `status`: één bestand per unieke waarde, zodat een puntzoekopdracht alleen het bestand met de overeenkomende waarde hoeft te lezen
- unieke indexen voor velden zoals `slug`: ze worden tijdens het schrijven afgedwongen; een dubbele waarde veroorzaakt een fout bij `put()` voordat er iets wordt geschreven
- bereikindexen voor scalaire waarden: een gesorteerd bestand met sparse seek-checkpoints, voor `gt`, `gte`, `lt`, `lte`, `between` en `prefix`

Bereikindexen kunnen ook `orderBy` op hetzelfde veld beantwoorden met een `limit`, rechtstreeks op basis van de indexvolgorde, oplopend of aflopend, zonder het volledige resultaat in het geheugen op te bouwen en te sorteren.

Wanneer een query twee `eq`-predicaten combineert op velden met een niet-unieke gelijkheidsindex, kan storh automatisch een samengestelde bucket voor dat veldpaar gebruiken. Zo blijven selectieve filters op twee velden snel zonder dat u een extra index hoeft te definiëren.

## Consistentie en herstel

Schrijfbewerkingen werken indexvermeldingen bij nadat het recordbestand atomair is vervangen, onder het schrijfslot van de collectie, zodat records en indexen samen worden bijgewerkt. `verify()` vergelijkt elke index met een volledige scan van de records en rapporteert afwijkingen; `reindex()` bouwt elke geconfigureerde index opnieuw op uit de recordbestanden; `repair()` zet beschadigde records in quarantaine en bouwt de indexen vervolgens opnieuw op.

```php
$docs->reindex();

$plan = $docs
    ->query()
    ->where('slug')->eq('home')
    ->explain();
```

`explain()` retourneert `index_scan` wanneer de planner een geconfigureerde index kan gebruiken, en anders `full_scan`.
