Ett index, klustrade eller icke-klustrade, kan användas av frågeoptimeraren om och endast om nyckeln längst till vänster i indexet filtreras på. Så om du definierar ett index på kolumner (A, B, C), ett WHERE-villkor på [email protected] , på [email protected] eller på [email protected] AND [email protected] kommer inte att utnyttja indexet fullt ut (se not). Detta gäller även anslutningsvillkor. Alla WHERE-filter som innehåller A kommer att överväga indexet:[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 ditt exempel om du gör det klustrade indexet på part_no som nyckeln längst till vänster, sedan en fråga som letar efter ett specifikt part_id kommer inte använd indexet och ett separat icke-klustrat index måste finnas på part-id .
Nu om frågan vilket av de många indexen som ska vara klustrade ett. Om du har flera frågemönster som har ungefär samma betydelse och frekvens och motsäger varandra när det gäller de nycklar som behövs (t.ex. frekventa frågor av endera part_no eller part_id ) så tar du hänsyn till andra faktorer:
- bredd :den klustrade indexnyckeln används som uppslagsnyckel av alla andra icke-klustrade index. Så om du väljer en bred nyckel (säg två uniquiidentifier-kolumner) så gör du alla andra index bredare, vilket förbrukar mer utrymme, genererar mer IO och saktar ner allt. Så mellan lika bra nycklar ur lässynpunkt, välj den smalaste som klustrade och gör de bredare icke-klustrade.
- påstående :om du har specifika mönster för infogning och borttagning, försök att separera dem fysiskt så att de förekommer på olika delar av det klustrade indexet. T.ex. om tabellen fungerar som en kö med alla inlägg i ena logiska änden och alla borttagningar i den andra logiska änden, försök att layouta det klustrade indexet så att den fysiska ordningen matchar denna logiska ordning (t.ex. köordning).
- partitionering :om tabellen är mycket stor och du planerar att distribuera partitionering måste partitioneringsnyckeln vara det klustrade indexet. Ett typiskt exempel är historisk data som arkiveras med hjälp av ett partitioneringsschema för glidande fönster. Även om enheterna har en logisk primärnyckel som 'entity_id', görs det klustrade indexet av en datetime-kolumn som också används för partitioneringsfunktionen.
- stabilitet :en nyckel som ändras ofta är en dålig kandidat för en klustrad nyckel eftersom varje uppdaterar det klustrade nyckelvärdet och tvingar alla icke-klustrade index för att uppdatera söknyckeln de lagrar. Eftersom en uppdatering av en klustrad nyckel också kommer att flytta posten till en annan sida kan det orsaka fragmentering av det klustrade indexet.
Obs:inte helt utnyttja eftersom motorn ibland väljer ett icke-klustrat index för att skanna istället för det klustrade indexet helt enkelt för att det är smalare och därför har färre sidor att skanna. I mitt exempel om du har ett index på (A, B, C) och ett WHERE-filter på [email protected] och frågeprojektet C , kommer indexet troligen att användas men inte som en sökning, som en skanning, eftersom det fortfarande är snabbare än en fullständig klustrad skanning (färre sidor).