Tips på hur du optimerar täckande SQL Server Index
Förord
Om du måste använda icke-Clustrat Index (eftersom ditt enda Clustrade Index behövs bättre någon annanstans i tabellen), och om du vet att din applikation kommer att köra samma SQL-sats om och om igen mot din tabell, så bör du överväga att skapa ett täckande Index på tabellen. Ett täckande Index, som är en form av kombinerat Index, inkluderar alla de kolumner som det refereras till från SELECT, JOIN och WHERE klausuler i en SQL-sats. Tack vare det så kommer Indexet att innehålla alla data som du behöver komma åt, så SQL Server behöver inte leta upp alla data i själva tabellen. Det reducerar både fysisk och/eller logisk I/O.
Innehåll
Tips på hur du optimerar täckande SQL Server Index
Å andra sidan, om det täckande Indexet blir väldigt stort (för många kolumner) så kan det öka I/O och sänka prestandan. När du skapar ett täckande Index så bör du generellt sett följa följande riktlinjer:
- Om SQL-satsen eller satserna som du kör använder sig av ett täckande Index som sällan körs, så kan den arbetslast som skapas av det täckande Indexet väga över de fördelar som annars ges.
- Det täckande Indexet bör inte lägga till någon särskild storlek på nyckeln. Om det gör det så väger inte fördelarna över så mycket.
- Det täckande Indexet måste inkludera alla kolumner som ges i SELECT listan, JOIN klausulen och WHERE klausulen.
[SQL Server 6.5, 7.0, 2000] Uppdaterad 02-08-09.
*****
Om en SQL-sats använder sig av kod som förminskar resultat, och om den används ofta, då bör du överväga att lägga till ett täckande Index för den här SQL-satsen. Icke-Clustrade Index inkluderar en post med ett Indexnyckelvärde för varje post i tabellen. På grund av det så kan SQL Server använda dessa inlägg på Indexets lövnivå för att utföra förminskningskalkyleringar. Det innebär att SQL Server inte måste gå in i själva tabellen för att utföra sina förminskningskalkyleringar, vilket kan höja prestandan. [SQL Server 6.5, 7.0, 2000] Inlagd 10-10-17
*****
Om du vill skapa ett täckande Index så bör du – om det är möjligt – försöka ”piggy-back” på redan existerande Index i den tabellen. Låt oss t ex säga att du behöver skapa ett täckande Index för kolumnerna c1 och c3. Men om du redan har ett index på c1 så kan du (istället för att skapa ett helt nytt täckande Index) göra om det existerande Indexet påc1 till ett täckande Index över både c1 och c3. Ju oftare du kan förhindra att Indexera samma kolumn fler än en gång, desto mindre I/O belastning får SQL Servern utstå och desto snabbare blir prestandan. [SQL Server 6.5, 7.0, 2000] Inlagd 01-10-17.
*****
Hur kan du se om det täckande Indexet som du skapade faktiskt används av Query Optimizern? Du kan få reda på det genom att aktivera och granska den grafiska exekveringsplanens output. Om du ser den här meningen; ”Scanning a non-clustered index entirely or only a range”, så innebär det att Query Optimizern lyckades täcka just den specifika SQL-satsen med ett Index. [SQL Server 7.0, 2000] Inlagd 00-10-17.
*****
En alternativ väg till att skapa täckande Index på icke-Clustrat Index är genom att låta SQL Server skapa det täckande Indexet åt dig automatiskt. Det fungerar så här:
Query Optimizer kan utföra det vi kallar en Index Intersection (Index genomskärning). Det här låter Optimizern att se över flertalet olika Index i en tabell och sedan skapa en Hash tabell baserat på dessa Index. Denna Hash tabellen kan sedan användas för att reducera I/O för den SQL-satsen. På så sätt så blir Hash tabellen som ett täckande Index för SQL-satsen.
Trots att Index Intersection utförs automatiskt av Query Optimizern så kan du hjälpa den lite på vägen genom att skapa icke-Clustrade Index innehållande en enda kolumn av alla de kolumner som kommer att frågas ut ofta av SQL-satsen. Det här ger Query Optimizern alla data den behöver för att kunna skapa täckande Index av bara farten. [SQL Server 7.0, 2000]
*****
Ett sätt att se ifall det täckande Indexet kommer att hjälpa en SQL-sats prestanda är genom att skapa en grafisk exekveringsplan av SQL-satsen i fråga i Query Analyzer, och sedan se om det utförs några Bookmark Lookups. Vanligtvis så talar Bookmark Lookups om för dig att Query Processorn var tvungen att leta efter de postkolumner som den behövde från en tabell eller ett Clustrat Index, istället för att kunna läsa det direkt från ett icke-Clustrat Index. Bookmark Lookups kan minska på en SQL-sats prestanda eftersom de skapar extra disk I/O för att hämta tillbaka alla kolumndata.
Ett sätt att undvika Bookmark Lookups på är genom att skapa täckande Index. På så sätt blir alla kolumner i SQL-satsen tillgängliga direkt från det icke-Clustrade Indexet. Det innebär att Bookmark Lookups blir onödiga, vilket reducerar disk I/O och höjer prestandan. [SQL Server 7.0, 2000] Inlagd 02-08-15.
0 Kommentarer