Et indeks, klynget eller ikke-klynget, kan bruges af forespørgselsoptimeringsværktøjet, hvis og kun hvis nøglen længst til venstre i indekset er filtreret på. Så hvis du definerer et indeks på kolonner (A, B, C), en WHERE-betingelse på [email protected] , på [email protected] eller på [email protected] AND [email protected] vil ikke udnytte indekset fuldt ud (se note). Dette gælder også tilslutningsbetingelser. Ethvert WHERE-filter, der inkluderer A vil overveje indekset:[email protected] eller [email protected] AND [email protected] eller [email protected] AND [email protected] eller [email protected] AND [email protected] AND [email protected] .
Så i dit eksempel, hvis du laver det klyngede indeks på part_no som nøglen længst til venstre, derefter en forespørgsel, der leder efter en specifik part_id vil ikke brug indekset, og et separat ikke-klynget indeks skal eksistere på part-id .
Nu om spørgsmålet, hvilket af de mange indekser der skal være klyngede en. Hvis du har flere forespørgselsmønstre, der har omtrent samme betydning og hyppighed og modsiger hinanden med hensyn til de nødvendige nøgler (f.eks. hyppige forespørgsler fra enten part_no eller part_id ) så tager du andre faktorer i betragtning:
- bredde :den klyngede indeksnøgle bruges som opslagsnøgle af alle andre ikke-klyngede indekser. Så hvis du vælger en bred nøgle (f.eks. to uniquiidentifier-kolonner), så gør du alle de andre indekser bredere, og bruger dermed mere plads, genererer mere IO og bremser alt. Så mellem lige gode taster fra et læsesynspunkt skal du vælge den smalleste som klyngede og gøre de bredere ikke-klyngede.
- påstand :hvis du har specifikke mønstre for indsættelse og sletning, prøv at adskille dem fysisk, så de forekommer på forskellige dele af det klyngede indeks. For eksempel. hvis tabellen fungerer som en kø med alle indsættelser i den ene logiske ende og alle sletninger i den anden logiske ende, så prøv at layoute det klyngede indeks, så den fysiske rækkefølge matcher denne logiske rækkefølge (f.eks. kørækkefølge).
- partitionering :hvis tabellen er meget stor, og du planlægger at implementere partitionering, skal partitioneringsnøglen være det klyngede indeks. Typisk eksempel er historiske data, der er arkiveret ved hjælp af et glidende vinduespartitioneringsskema. Selvom entiteterne har en logisk primærnøgle som 'entity_id', udføres det klyngede indeks af en datetime-kolonne, der også bruges til partitioneringsfunktionen.
- stabilitet :en nøgle, der ofte ændres, er en dårlig kandidat til en klynget nøgle, da hver enkelt opdaterer den klyngede nøgleværdi og fremtvinger alle ikke-klyngede indekser for at opdatere den opslagsnøgle, de gemmer. Da en opdatering af en klynget nøgle sandsynligvis også vil flytte posten til en anden side, kan det forårsage fragmentering af det klyngede indeks.
Bemærk:ikke helt udnytte, da motoren nogle gange vælger et ikke-klynget indeks til at scanne i stedet for det klyngede indeks, simpelthen fordi det er smallere og dermed har færre sider at scanne. I mit eksempel, hvis du har et indeks på (A, B, C) og et WHERE-filter på [email protected] og forespørgslen projekterer C , vil indekset sandsynligvis blive brugt, men ikke som en søgning, som en scanning, fordi det stadig er hurtigere end en fuld klyngescanning (færre sider).