Hvad er forskellen mellem en tabelscanning og en klynget indeksscanning?

I en tabel uden et klynget indeks (en heap-tabel) er datasider ikke linket sammen - så at krydse sider kræver en opslag i Index Allocation Map .

En klynget tabel har dog sine datasider linket i en dobbelt linket liste - gør sekventielle scanninger lidt hurtigere. Til gengæld har du selvfølgelig overhead til at holde orden på datasiderne på INSERT , UPDATE og DELETE . En heap-tabel kræver dog endnu en skrivning til IAM.

Hvis din forespørgsel har en RANGE operator (f.eks.:SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100 ), så ville en klynget tabel (der er i en garanteret rækkefølge) være mere effektiv - da den kunne bruge indekssiderne til at finde de(n) relevante dataside(r). En bunke ville skulle scanne alle rækker, da den ikke kan stole på bestilling.

Og selvfølgelig giver et klynget indeks dig mulighed for at udføre en KLUSTERET INDEX SEEK, hvilket er stort set optimalt for ydeevne...en bunke uden indeks ville altid resultere i en tabelscanning.

Så:

• For din eksempelforespørgsel, hvor du vælger alle rækker, er den eneste forskel den dobbeltlinkede liste, som et klynget indeks vedligeholder. Dette skulle gøre din klyngede tabel bare en lille smule hurtigere end en bunke med et stort antal rækker.

• For en forespørgsel med en WHERE klausul, der (i det mindste delvist) kan opfyldes af det klyngede indeks, kommer du foran på grund af bestilling - så du behøver ikke at scanne hele tabellen.

• For en forespørgsel, der ikke er opfyldt af det klyngede indeks, er du stort set lige... igen, den eneste forskel er den dobbelt-linkede liste til sekventiel scanning. I begge tilfælde er du suboptimal.

• For INSERT , UPDATE og DELETE en bunke kan eller måske ikke vinde. Heapen behøver ikke at opretholde orden, men kræver endnu en skrivning til IAM. Jeg tror, ​​at den relative præstationsforskel ville være ubetydelig, men også ret dataafhængig.

Microsoft har en whitepaper som sammenligner et klynget indeks med et tilsvarende ikke-klynget indeks på en heap (ikke nøjagtig det samme som jeg diskuterede ovenfor, men tæt på). Deres konklusion er grundlæggende at sætte et klynget indeks på alle tabeller. Jeg vil gøre mit bedste for at opsummere deres resultater (igen, bemærk, at de virkelig sammenligner et ikke-klynget indeks med et klynget indeks her - men jeg tror, ​​det er relativt sammenligneligt):

• INSERT ydeevne:clustered index vinder med omkring 3 % på grund af den anden skrivning, der er nødvendig for en heap.
• UPDATE ydeevne:grupperet indeks vinder med omkring 8 % på grund af det andet opslag, der er nødvendigt for en heap.
• DELETE ydeevne:clustered index vinder med omkring 18 % på grund af det andet opslag, der er nødvendigt, og den anden sletning, der er nødvendig fra IAM for en heap.
• enkelt SELECT ydeevne:clustered index vinder med omkring 16 % på grund af det andet opslag, der er nødvendigt for en heap.
• interval SELECT ydeevne:clustered index vinder med omkring 29 % på grund af den tilfældige bestilling af en heap.
• samtidig INSERT :Heap-tabellen vinder med 30 % under belastning på grund af sideopdelinger for det klyngede indeks.