Heap-tabeller I SQL Server

i det siste innlegget i denne bloggserien diskuterte jeg hva En b-treindeks var og forklarte kort sin historie.

Før vi dykker inn i indeksene SOM SQL Server bruker, er det viktig å sette grunnlaget for datastrukturer. Det mest grunnleggende bordet du kan opprette er en haug. En haug er en usortert struktur av sider som ikke er koblet til hverandre.

når skal du bruke hauger?

anbefalingen for beste praksis er å unngå SQL Server-hauger, i de fleste tilfeller. Kimberly Tripp forklarer noen av grunnene og debatten her, men jeg vil dekke høyt nivå. Heaps, som er den mest grunnleggende lagringsstrukturen, mangler funksjoner som forbedrer ytelsen for normale (OLTP) arbeidsbelastninger. Noen hevder at hauger er bedre for utdrag, transformasjon og lasting (ETL) operasjoner fordi det er færre sider å opprettholde under skriveoperasjoner (OPPDATER/SETT INN/SLETT). Spesielt kan hauger være raskere enn en b-treindeks hvis sidesplitt oppstår, og mange nivåer av indeksen må oppdateres. I tillegg er radidentifikatoren (RID), diskutert mer nedenfor, bare 8 byte. Dette kan gi bedre resultater enn en gruppert indeks med mange nøkkelkolonner fordi ikke-grupperte indekser må lagre den grupperte nøkkelen eller RID for hver indekserte rad. Vanligvis anbefaler jeg å bruke en gruppert indeks (mer på grupperte indekser når vi fortsetter denne serien) i stedet for en bunke, men hvis du bruker dem, bruk dem bare når du har bevist at de vil være mer effektive enn en gruppert indeks. Etter å ha diskutert en haug struktur, vil jeg skissere ytelsen bekymringer for å bruke hauger.

Heap struktur

en heap er en gruppering av usorterte sider som ikke er koblet. Siden anatomi er ute av omfang for denne serien siden alle typer indekserte og ikke-indekserte tabeller bruker samme sidestruktur, men jeg oppfordrer deg til å sjekke ut her og her for å lære mer.

en heap består av en eller flere indeksallokeringskart (iam) sider som peker til datasidene som utgjør heap. Det eneste unntaket til dette er nar du har rad som har blitt oppdatert og ikke kunne passe inn i siden lenger. I så fall får du en videresendingspeker til raden som er flyttet til en eksisterende side med mellomrom eller en ny side. Det er mulig for deg å produsere en kjede med videresendingsposter hvis raden fortsetter å trenge flytting ved videre operasjoner.

heap-structure-1

bildereferanse:MSDN

en heap har en rad i sys.partisjoner per partisjon og dens index_id vil være lik null. I denne posten peker first_iam_page til den første av sidene for indeksallokeringskart (iam). En IAM-side kartlegger sider for hver tildelingsenhet og administrerer 4 GB biter av tabellen. Tildelingsenheter inkluderer:

  1. in_row_data tildelingsenhet
  2. LOB_DATA tildelingsenhet
  3. ROW_OVERFLOW_DATA tildelingsenhet

IAM-siden inneholder standard 96-byte-hodet etterfulgt av IAM-hodet. IAM header begynner med åtte spor for blandede grad tildelinger og deretter en 8000-byte bit-kart for å finne uniform extents allokert til bordet.

en blandet utstrekning er en som inneholder sider fra mer enn ett bord. Dette er også referert til som en delt omfang. Formålet med en blandet grad er å spare plass med tabeller som er mindre enn 64 KB. En enhetlig utstrekning er en der alle sider i utstrekning tilhører det enkle bordet.

mixed-extent

Bildereferanse: Omfanget

for å undersøke VÅR IAM-side må vi først finne den.

dbcc IND (‘demo’, ‘ dbo.demo’,1)

dbcc-ind

Med DBCC IND har vi 17 datasider og 1 IAM-side. IAM-sider er ikke selvrefererende, derfor ER IAMFID (iam-Fil-Id) OG IAMPID (iam-Side-Id) NULL. Dette betyr at VÅR IAM-side er i fil-Id (PageFID) 1 og er side-Id (PagePID) 297. DBCC-SIDEN vil tillate oss å se VÅR IAM-side.

DBCC TRACEON(3604);

dbcc SIDE (‘demo’,1,297,3);

dbcc-page-iam

I GULT er det åtte enkelt side tildelinger i vår blandet omfang. I ORANSJE vises uniform extents i områder.

Ytelses implikasjoner

Utføre ulike data manipulation language (DML) operasjoner på en heap har disse påvirker.

  • SETT Inn-Nye rader kan plasseres på den første tilgjengelige siden med tilstrekkelig plass. Så når en ny rad er satt inn, vil den sannsynligvis bli lagt til den siste siden.
  • OPPDATERING-Rader kan forbli på samme side hvis Den passer på siden etter oppdateringen, hvis ikke vil den bli fjernet fra gjeldende side og plassert på den første tilgjengelige siden med tilstrekkelig plass og en videresendingspeker er skrevet på den opprinnelige siden.
  • DELETE-Data blir ikke overskrevet, plass er bare flagget som tilgjengelig for gjenbruk. Dette kan føre til at tabellen bruker betydelig mer diskplass enn nødvendig.
  • VELG-en tabellskanning på hele tabellen må leses for de fleste spørringer. Unntaket til dette er når det er en egnet ikke-gruppert indeks tilgjengelig. Vi vil diskutere ikke-grupperte indekser senere i denne serien.

Leser

uten noen støtteindeks krever en heap en fullstendig tabellskanning for alle spørringer. Dette er fordi den fysiske strukturen er un-sortert, og det er ingen side linking til støtte områdeskanninger.

SETT STATISTIKK IO PÅ

DBCC IND (‘demo’, ‘ dbo.demo’,1)

VELG ANTALL ( * )
FRA dbo.demo

Gjenta vår DBCC IND-kommando ovenfra minner oss om at vi har 18 sider for denne tabellen. 17 datasider og 1 IAM-side.

– Fjernet DBCC IND-resultater fordi det allerede vises ovenfor.
-18 radresultat, angir 18 sider.

(18 rad(er) berørt)
dbcc-kjøring fullført. Hvis DBCC trykte feilmeldinger, kontakt systemadministratoren.

RowCount
—-
5031
(1 rad (er) berørt)

Tabell ‘Demo’. Scan count 1, logisk leser 17, fysisk leser 0, lese-fremover leser 0, lob logisk leser 0, lob fysisk leser 0, lob lese-fremover leser 0.
(1 rad (er) berørt)

Merk de 17 logiske lesingene fra spørringen vår. Dette skyldes AT IAM-siden ikke telles i den logiske leser metriske og vi utførte en full skanning av tabellen med 18 sider.

Skriver og frem pekere

Som nevnt ovenfor, Setter Inn Og Sletter er ganske rett frem. EN INNSATS skjer på den første siden med ledig plass, selv om det betyr opprettelse av en ny side. Sletter utføres ved å de-tildele plassen raden var opptar.

Oppdateringer er Hvor ting går nedoverbakke for hauger. Når en fast lengde datatype oppdateres oppdateringen vil skje på stedet. Hvis en datatype med variabel lengde oppdateres og lengden har økt, er det en sjanse for at raden ikke lenger får plass på samme side. Når raden ikke lenger passer, plasseres en videresendingspeker i området der den opprinnelige raden var, og raden flyttes til en ny side. Denne prosessen har en negativ innvirkning på leseytelsen. La oss demonstrere.

Opprinnelig Alle våre poster i dbo.demo tabellen inneholdt VARCHARs med 9 tegnstrenger.

VELG TOPP 5 *
FRA dbo.demo

 demo tabelldata

for å lage noen fremadrettede pekere oppdaterer vi alle våre rader og øker lengden på varlen-kolonnen.

oppdater dbo.demo
sett varLen = replikere (‘a’,100)

Vi har nå 95 sider i vår haug fordi alle våre rader har blitt flyttet til nye sider med frem pekere igjen.

dbcc IND (‘demo’, ‘ dbo.demo’,1)

dbcc-output-1

Som du kan forestille deg, med hauger som krever full tabellskanninger, må vi lese mange flere sider for samme mengde poster nå.

SETT STATISTIKK IO PÅ

VELG ANTALL (*)
fra dbo.demo
(1 rad (er) berørt)

Tabell ‘Demo’. Scan count 1, logisk leser 4405, fysisk leser 0, read-ahead leser 0, lob logisk leser 0, lob fysisk leser 0, lob read-ahead leser 0.

våre leser økt drastisk fordi de opprinnelige sidene måtte leses og deretter frem pekere måtte følges. Ytelsen innvirkning og sløsing med plass i minnet og på disken er grunnen til at vi trenger grupperte indekser.

Neste gang

heap-datastrukturen er ikke en indeks og er ofte den verste utførende datastrukturen for tabellene i SQL Server. Vi dekket det i dag som et grunnlag for forståelse som vil være nyttig når vi diskuterer indekser. I neste del av denne serien vil grupperte indekser, En b+-trestruktur for tabelldata, bli dekket.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.