Wat is het verschil tussen een tabelscan en een geclusterde indexscan?

In een tabel zonder een geclusterde index (een heap-tabel) zijn gegevenspagina's niet aan elkaar gekoppeld - dus het doorlopen van pagina's vereist een zoek de indextoewijzingskaart op .

Een geclusterde tabel heeft echter zijn gegevenspagina's die zijn gekoppeld in een dubbel gelinkte lijst - sequentiële scans iets sneller maken. In ruil daarvoor heb je natuurlijk de overhead om de gegevenspagina's op orde te houden op INSERT , UPDATE , en DELETE . Een heap-tabel vereist echter een tweede schrijfactie naar de IAM.

Als uw zoekopdracht een RANGE . heeft operator (bijv.:SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100 ), dan zou een geclusterde tabel (in een gegarandeerde volgorde) efficiënter zijn - omdat deze de indexpagina's zou kunnen gebruiken om de relevante gegevenspagina('s) te vinden. Een hoop zou alle rijen moeten scannen, omdat het niet kan vertrouwen op bestellen.

En natuurlijk kun je met een geclusterde index een CLUSTERED INDEX SEEK doen, wat vrijwel optimaal is voor prestaties... een heap zonder indexen zou altijd resulteren in een tabelscan.

Dus:

• Voor uw voorbeeldquery waarbij u alle rijen selecteert, is het enige verschil de dubbel gekoppelde lijst die een geclusterde index bijhoudt. Dit zou je geclusterde tabel net een klein beetje sneller moeten maken dan een hoop met een groot aantal rijen.

• Voor een zoekopdracht met een WHERE clausule waaraan (althans gedeeltelijk) kan worden voldaan door de geclusterde index, komt u op voorsprong door de volgorde - u hoeft dus niet de hele tabel te scannen.

• Voor een zoekopdracht die niet wordt bevredigd door de geclusterde index, ben je vrijwel gelijk... nogmaals, het enige verschil is die dubbel gelinkte lijst voor sequentiële scanning. In beide gevallen ben je niet optimaal.

• Voor INSERT , UPDATE , en DELETE een hoop kan wel of niet winnen. De heap hoeft de volgorde niet te handhaven, maar vereist wel een tweede schrijven naar de IAM. Ik denk dat het relatieve prestatieverschil verwaarloosbaar zou zijn, maar ook behoorlijk afhankelijk van de gegevens.

Microsoft heeft een whitepaper die een geclusterde index vergelijkt met een equivalente niet-geclusterde index op een hoop (niet precies hetzelfde als ik hierboven heb besproken, maar dichtbij). Hun conclusie is eigenlijk om een ​​geclusterde index op alle tabellen te zetten. Ik zal mijn best doen om hun resultaten samen te vatten (nogmaals, merk op dat ze hier echt een niet-geclusterde index vergelijken met een geclusterde index - maar ik denk dat het relatief vergelijkbaar is):

• INSERT prestatie:geclusterde index wint met ongeveer 3% dankzij de tweede schrijfactie die nodig is voor een hoop.
• UPDATE prestatie:geclusterde index wint met ongeveer 8% dankzij de tweede zoekopdracht die nodig is voor een hoop.
• DELETE prestatie:geclusterde index wint met ongeveer 18% dankzij de tweede zoekopdracht die nodig is en de tweede verwijdering die nodig is uit de IAM voor een hoop.
• enkele SELECT prestatie:geclusterde index wint met ongeveer 16% dankzij de tweede zoekopdracht die nodig is voor een hoop.
• bereik SELECT prestatie:geclusterde index wint met ongeveer 29% vanwege de willekeurige volgorde voor een hoop.
• gelijktijdige INSERT :heaptabel wint met 30% onder belasting vanwege paginasplitsingen voor de geclusterde index.