Mne jich napadá mnohem víc, ale jednoznačně je to covering index - select count(*) from marta where azor is not null* (podobně select azor, sysdate, 'Haf' from marta where azor is not null*) - pokud mam na azorovi index, tak tenhle sql přes něj může jít (respektive pouze do něj), což bude patrně rychlejší než aby ten count udělal přes full-table scan (větší počet datových bloků) a v podobných příkladech se jde do indexu nezávisle na tom jestli má nebo nemá nízkou selectivitu, pokud to co potřebuji dokážu vyčíst pouze z indexu, jdu pochopitelně jen tam a proto pořád může být oprávněný index nad sloupcem kde jsou 3 disticnt hodnoty ale řádků spoustu

Pokud mam dotaz, ktery pouztim jednou za pul roku, muze si uzivatel 2 minuty pockat

jop souhlas, me spis zaujala neopravnenost indexu, nevidel jsem to tak jasně.

S optimalizátory (vzhledem k tomu ze do nich vcelku dost vidím) nějak problém nemám, neb typicky vím proč tak jednají a ve většině případů si to dokáži zdůvodnit. Ačkoliv když je nouze používám hint parallel/dynamic sampling, protože to hustě naboří exekuční plány a jsou uplně jiné, což je fajn jedno slovo to dokáže celé překopat, ne vždy má člověk čas a chut koukat do exekučního plánu s >10 tabulkama a je tam vcelku rychlá šance na "výhru"

* -podmínka tam musí být neb do indexu nejdou nully (alternativně to tam být nemusí pokud nad tim sloupcem je constraint not null), pouze do bitmapového, ale tam se zase soupeří o bloky při parallením zpracování.

Akorád teda nerozumim té referenční integritě, co jsi psal v první větě, constrainty jsou (alespon za mne) na refrenčníní integritu a uplně jiné než indexy..