Brug af indekser og udførelse af tabel-scanninger er to grundlæggende tilgange til adgang til data i en database, hver med forskellige afvejninger afhængigt af situationen.
Et indeks i en database er en datastruktur, der muliggør hurtigere opslag ved at lade systemet hurtigt finde rækker uden at scanne hver række i tabellen. De fleste relationelle databaser bruger B+ Træstrukturer til indekser, der organiserer nøgler og tip i en træform. Dette tillader søgninger, indsættelser og sletninger i logaritmisk tidskompleksitet $$ O (\ log n) $$, hvilket typisk er meget hurtigere end at scanne hele bordet med en kompleksitet på $$ O (n) $$. Indekser kan klynges eller ikke-klynges, med grupperede indekser, der lagrer data i fysisk sorteret rækkefølge, hvilket forbedrer scanning af rækkevidde til prisen for ekstra overhead på datamodifikationer. Indekser kan også være sammensatte, delvise, filtrerede eller hash-baserede, indstillede til specifikke forespørgselsmønstre.
I modsætning hertil læser en tabelskanning (eller fuld tabelskanning) hver række i tabel sekventielt, uanset forespørgselsets selektivitet. Dette involverer scanning af alle datablokke på tabellen og betragtes ofte som den dyreste adgangsmetode, fordi den behandler flere data end nødvendigt. Imidlertid kan tabelskanninger fungere godt i visse tilfælde. For eksempel, når forespørgsler henter en stor procentdel af rækker, kan omkostningerne ved at bruge et indeks (som ofte kræver yderligere opslag til de faktiske rækker) overstige omkostningerne ved scanning af hele tabellen en gang. Tabel-scanninger kan gøre brug af flerbloklæsninger, som tillader at læse store bidder med data med færre I/O-operationer, hvilket reducerer latenstid sammenlignet med at læse mange individuelle blokke tilfældigt krævet af indeksscanninger.
En vigtig afvejning involverer selektivitet og størrelse af datasættet, der er returneret af forespørgslen. Hvis forespørgslen filtrerer ned til et lille antal rækker (høj selektivitet), er indekser generelt bedre end tabelscanninger, fordi de kun behøver at få adgang til de relevante data. Men efterhånden som procentdelen af returnerede stiger, stiger omkostningerne ved indeksscanningerne, da flere nøgleopslag kan være påkrævet, og databasemotoren skal udføre yderligere tilfældige I/O -operationer. På en eller anden tærskel, ofte omkring 10-20% af tabellens rækker, men afhængig af databredde og hardware, bliver en komplet bordscanning mere effektiv. Dette skyldes, at scanningsomkostningerne forbliver konstante uanset selektiviteten, blot at læse tabel sekventielt en gang.
Indeksscanninger læser typisk færre sider end en tabelskanning, når de dækkede kolonner er færre eller mere kompakte end de fulde tabelrækker. For eksempel kan et indeks kun omfatte de indekserede kolonner uden de fulde tabelrækkedata, hvilket gør dem tyndere og tillader flere rækker at passe på hver databaseside. Dette reducerer I/O -overhead, når du scanner indekset sammenlignet med at scanne hele tabeldataene. Derudover kan nogle indekser filtreres (delvise indekser) for at udelukke irrelevante rækker, hvilket yderligere reducerer scanningsfodaftrykket.
På den anden side skriver scanninger i fuld tabel mindre byrde på databasevedligeholdelsessiden. Indekser introducerer overhead under datamodifikationsoperationer såsom indsættelse, opdatering og sletning. Hver ændring af tabellen kræver opdatering af indekser, som undertiden fører til øget skrivning og opbevaringsomkostning, især hvis der findes mange indekser på bordet. Denne overhead kan også påvirke samtidigheden og føre til strid i tunge skrivemiljøer. Således undgår tabelskanninger, der simpelthen læser dataene i sin naturlige rækkefølge uden yderligere strukturvedligeholdelse, disse omkostninger.
En anden vigtig overvejelse er effekten af cache- og hardwareegenskaber. Tabel -scanninger drager fordel af sekventiel I/O og forhåndsudvikling, hvilket gør det muligt for systemet at læse flere sammenhængende blokke effektivt, ofte fra hukommelsen, hvis de er cache. Omvendt påfører indeksskanninger tilfældig I/O for at hente forskellige datablokke, især hvis indeksscanningen skal slå rækkepoints i bunkeopbevaring. Dette kan gøre indeksscanninger langsommere på systemer med langsommere disk tilfældig I/O -ydeevne, skønt SSD'er og store hukommelsespuljer indsnævrer dette hul. Situationen kan også afhænge af detaljer som parallelisme og multi-threading-kapaciteter i databasemotoren, hvor parallelle bordscanninger markant kan øge gennemstrømningen.
Derudover påvirker den interne fragmentering og fysiske opbevaringslayout performanceudvekslingerne. Tabelskanninger på bunkeorganiserede borde kan lide af videresendte poster, hvor rækker er flyttet til forskellige sider på grund af opdateringer, forværret scanningseffektivitet. Clustered -indekser, der gemmer data sorteret efter nøgle, kan undgå dette problem og undertiden gøre en "tabel scanning" svarende til en clustered indeksscanning. Fordelene kommer imidlertid med omkostningerne ved dyre række ombestillinger under tunge datakur.
Fra et forespørgselsoptimeringsperspektiv foretages beslutningen mellem en indeksscanning og en tabelskanning typisk af omkostningsbaserede estimeringsmodeller under hensyntagen til statistik om datafordeling, rækkeoptællinger og hardwareomkostninger. Optimizer afbalancerer CPU, I/O og hukommelsesomkostninger for at vælge den mest effektive adgangssti. Disse beslutninger kan påvirkes af faktorer som tilgængelig hukommelse, cache -tilstand og forespørgselsmønstre. Der er ingen fast tærskel mellem hvornår man skal bruge den ene eller den anden; Crossover -punktet varierer pr. System og arbejdsbyrde.
Sammenfattende inkluderer afvejningen mellem at bruge indekser og tabel-scanninger:
- Performance vs. datavolumen: Indekser overgår overfor, når de filtreres til få rækker; Tabel -scanninger kan være bedre til stor hentning af data.
- I/O -mønstre: Indeksscanninger forårsager tilfældige I/O -læsninger; Tabel-scanninger drager fordel af sekventiel I/O og flerbloklæsning.
- Vedligeholdelse overhead: Indekser Forøg skriveoperationsomkostninger på grund af opdateringer om indeksstrukturer; Tabelskanninger pådrager sig ikke dette.
- Opbevaringseffektivitet: Indekser kan være kompakte ved at dække færre kolonner; Tabelskanninger processer fulde rækker og potentielt flere data.
- Cache -effekter: Tabel -scanninger kan anvende data -cache effektivt, især med store sekventielle læsninger; Indeksscanninger drager muligvis ikke så meget på grund af tilfældig adgang.
- Optimizer-beslutning: Omkostningsbaserede forespørgselsoptimerne vælger dynamisk mellem disse indstillinger baseret på forespørgselsstatistikker og arbejdsbelastningsspecifikationer.
- Virkningen af datalayout: Heap -tabeller kan pådrage sig sanktioner som videresendte poster under scanninger; Clustered -indekser organiserer data fysisk, men øger opdateringsomkostningerne.