Databázové indexy

Preview:

DESCRIPTION

Databázové indexy. Lubom ír Andrle lubomir.andrle @ unicorn.eu 3 . přednáška 14 .10.201 3. Obsah. Co je index Struktura index u Jak se používá Časté chyby. Proč indexy. Slouží ke zrychlení vyhledávání dat Efektivní vynucování unique constraintů Z povahy jejich struktury - PowerPoint PPT Presentation

Citation preview

Databázové indexy

Lubomír Andrlelubomir.andrle@unicorn.eu

3. přednáška14.10.2013

Obsah

> Co je index> Struktura indexu> Jak se používá> Časté chyby

Proč indexy

• Slouží ke zrychlení vyhledávání dat• Efektivní vynucování unique constraintů– Z povahy jejich struktury

• Redukce I/O operací• Čtení dat bez přístupu do tabulky

Vztah indexů s ostatními objekty

Přehled schémat indexů

> B-tree index> B-tree cluster index> Hash cluster index> Reverse key index> Bitmap index> Bitmap join index

Příklad přístupu do tabulky

Bez indexu• Full table scan

– Výhodné pokud je Davidů hodně

Index• Index (range) scan

– Nejdřív do indexu a až pak do tabulky

– Nemusí být výhodné, pokud je Davidů hodně

Everybody repeat after me: „Full table scans are not bad” ;)

Struktura B-tree indexu• Root block• Branch block

– Klíč a pointer na první leaf block

• Leaf– Klíč a rowid – Pointer na předchozí a

následující leaf

Vlastnosti indexu

• Balanced– Všechny leaf blocky jsou stejně daleko od rootu

• Setříděné záznamy– Zleva do prava

• Single-block ready– Multi-block ready jen ve spec. případě

Statistiky indexu• B-level

– Výška indexu mezi root block a leaf– Definuje minimální počet „getů“ potřebných k projití indexu– Hloubka indexu = B-level + 1

• Leaf blocks– Average leaf blocks per key

• Průměrný počet leaf blocks potřebných projít v případě uložení hodnoty

– Average data blocks per key• Průměrný počet table blocks, která obsahují řádky referencované z klíče indexu

Statistiky indexu II• Clustering factor (CF)

– Velmi silná statistika hýbající s cenou přístupu– Představuje jak dobře jsou setříděny řádky v tabulce vůči indexu– Statistika používaná CBO (Cost based optimizer) pro určení „ceny“ indexu– Problematický výpočet– Ne vždy odpovídá realitě

• Kde je hledat– user_indexes– v$index_stats

Index s perfektním CF

Index se slabým CF

PRÁCE S INDEXY

Metody přístupu do indexu> Metody

> Unique scan> Range scan> Full scan> Fast full scan> Skip scan> Min/max> Optimalizované joiny

> Přístupy do indexu jsou vždy single-block> db file sequential read> Výjimka Fast full scan

Unique scan• Jeden z nejefektivnějších přístupů k datům• Použit v případě jedinečných hodnot indexu

– Primary key, Unique constraint• Vrací vždy maximálně jeden řádek

>=N

>=I>=E

A,C,.. F,H ,.. I,J ,K

>=V>=Q

N,P R,U V,Z

Tabulka

Range scan

• Běžná operace pro přístup k výběru hodnot• Data vrácena setříděna – Defaultně vzestupně– Více řádků s identickými hodnotami seřazeny

podle ROWID

Range scan - příklad• col1 = :b1• col1 < :b1; col1 > :b1• col1 like 'ASD%'• where col1 between 'J' and 'T'

>=N

>=I>=E

A,C ,.. F,H ,.. I,J ,K

>=V>=Q

N,P R,U V,Z

Tabulka

Full scan

• Vlastně range scan bez omezení

>=N

>=I>=E

A,C,.. F,H ,.. I,J ,K

>=V>=Q

N,P R,U V,Z

Tabulka

Skip scan - příklad

• Tabulka Employees – Sloupce id, pohlaví

• SELECT * FROM employees WHERE employee_id = 101;

Min/max

• Hledá minimum nebo maximum na základě branches

>=N

>=I>=E

A,C,.. F,H ,.. I,J ,K

>=V>=Q

N,P R,U V,Z

Fast full scan• Alternativa k full scan v případě, kdy všechny sloupce

dotazu jsou součástí indexu– Není nutný přístup do tabulky

• Multi-block read– Využití paralelního přístupu

• Ignoruje branch bloky a strukturu indexu vůbec

• Data nejsou řazena

>=N

>=I>=E

A,C,..

F,H,..

>=V>=Q

N,P

Náročnost čtení indexu

> Jde vždy o LIO (logické I/O)> B-level + (leaf bloky * selektivita indexu) +

(clustering factor * selektivita tabulky)> Pravidlo 95/5

> „Na jeden klíč max. čtení 5% indexu“> CBO

> Pokud jsou statistiky přesné, spočítá to za vás

Náročnost zápisu do indexu

> Typicky největší overhead při použití indexu> Zápis vždy při

> Insert> Delete> Update

> ( = insert + delete )

> Vlastní redo> Konkurence

Split indexu

• 50/50 split při zaplnění leaf-blocku

Split indexu II

• 90/10 split při zaplnění leaf-blocku– Speciální případ, pouze směrem doprava

Split indexu - konkurence

> Během splitu se čeká …> Vlastní Redo> Propaguje se vždy směrem nahoru

> Always balanced> Root block – jediný se nikdy nemění

SPECIÁLNÍ PŘÍPADY

Složené indexy

> Index nad více sloupci tabulky> Zvýšení rychlosti v případech, kdy where

podmínka obsahuje všechny sloupce indexu> Záleží na pořadí sloupců!

Function-based indexy

• Poskytuje efektivní mechanismus pro vyhodnocení příkazů, které obsahují funkci ve where podmínce

• Pozor na Null hodnotu– Není v indexu ukládána– Trik s decode

• Create index ix1 on tab1 (decode(status,'X',null))

• Příklad– CREATE INDEX idx ON table_1 (a + b * (c - 1), a, b);

Reverse-key indexy

• Navrhnut k randomizaci indexovaných hodnot napříč strukturou indexu

• Typicky u front v RAC• Opatrně, může mít zásadní overhead• Randomizace v rámci celého indexu– Např. Při použití seq (1000) a „hot blocku“

Partitioning indexes

• Lokální index

• Globální index– Nad celou tabulkou– Typicky použité

pro OLAP

Bitmap index

• MARITAL_STATUS, GENDER mají nízkou kardinalitu

• Struktura indexu pro sloupec REGION

Bitmap index

• Ukázka použití bitmap indexu

ČASTÉ CHYBY

Příliš mnoho indexů

> Velký overhead> AWR (Automatic Workload Repository)

> Prohledání plánů> Indexovat podle toho, co chceme hledat> Výjimkou jsou Foreign Keys

Špatné pořadí sloupců

> Nekompatibilní predikáty> Optimizer pak musí použít špatnou metodu

přístupu> Where podmínka neodpovídá ani jednomu

indexu> Index (col1), index (col2)

> Where col1 = x and col2 = y> Měl by být složený ;)

Použití OR kde není potřeba

• Ukázka– Výchozí hodnota sloupce Sl1 (not null)– Občas nutný override Sl2 (null)– Select … where Sl1 = ‘value’ or Sl2 = ‘value’

Rebuild indexu> Téměř nikdy není potřeba

> Index se sám stále vyrovnává a čistí> Často velice drahý

> Konkurence> Redo> CPU

> Může zbytečně index rozmělnit> Je potřeba pokud

> Velké nárazové akce> Masivní delete, které ovlivní celý index> Fronty – typicky je všechno zajímavé úplně vpravo a index je zbytečně velký

Špatné plány

> Zbytečné full scany indexů> CPU > Db file sequential read

> Zbytečné přístupy do tabulek> Špatné where podmínky

Q&A

Recommended