Ik wil alleen een woord van waarschuwing plaatsen:alsjeblieft heel voorzichtig kies uw geclusterde index! Elke "gewone" gegevenstabel zou een geclusterde index moeten hebben, aangezien het hebben van een geclusterde index inderdaad veel bewerkingen versnelt - ja, versnellen , zelfs invoegingen en verwijderingen! Maar alleen als je een goede kiest geclusterde index.
Het is de meest gerepliceerde gegevensstructuur in uw SQL Server-database. De clustersleutel maakt ook deel uit van elke niet-geclusterde index op uw tafel.
U moet uiterst voorzichtig zijn bij het kiezen van een clustersleutel - deze moet zijn:
-
smal (4 bytes ideaal)
-
uniek (het is tenslotte de "rijaanwijzer". Als u het niet uniek maakt, doet SQL Server het voor u op de achtergrond, wat u een paar bytes kost voor elke invoer maal het aantal rijen en het aantal niet-geclusterde indices dat u hebben - dit kan erg duur zijn!)
-
statisch (nooit wijzigen - indien mogelijk)
-
idealiter steeds toenemend zodat u geen vreselijke indexfragmentatie krijgt (een GUID is het tegenovergestelde van een goede clustersleutel - om die specifieke reden)
-
het moet niet-nullable zijn en idealiter ook een vaste breedte - a
varchar(250)maakt een zeer slechte clustersleutel
Al het andere zou echt het tweede en derde niveau van belang moeten zijn achter deze punten ....
Bekijk enkele van Kimberly Tripp's (The Queen of Indexing ) blogberichten over het onderwerp - alles wat ze op haar blog heeft geschreven is absoluut van onschatbare waarde - lees het, verwerk het - leef ernaar!
- GUID's als PRIMAIRE SLEUTELS en/of de clustersleutel
- Het geclusterde indexdebat gaat door...
- Steeds toenemende clusteringsleutel - het geclusterde indexdebat..........nogmaals!
- Schijfruimte is goedkoop - dat is niet het punt!