Tips på hur du optimerar SQL Serverns Clustrade Index
Förord
Som en tumregel så bör varje tabell i varje databas ha ett Clustrat Index. Generellt sett (men inte alltid) så bör det Clustrade Indexet finns på en kolumn som ökar monotont, såsom identitetskolumner eller andra kolumner där värdet ökar (och är unikt). I många fall så är primärnyckeln en ideal kolumn för ett Clustrat Index. Om du har någon erfarenhet med att optimera prestandan i SQL Server 6.5 så kanske du har hört att det inte är någon bra idé att sätta Clustrade Index på kolumner där värdena ökar monotont, eftersom det kan skapa en så kallad ”hotspot” på hårddisken och därmed skapa vissa prestandaproblem. Det är sant i SQL Server 6.5.Innehåll
Tips för hur du optimerar SQL Serverns Clustrade Index
I SQL Server 7.0 och 2000 så orsakar dessa ”hotspots” generellt sett inte några problem. För att en ”hotspot” ska kunna ha en negativ påverkan på prestanda i SQL Server 7.0 och 2000 så måste du ha över 1 000 transaktioner per sekund. Faktum är att du under dessa omständigheter kan dra fördel av ”hotspots” eftersom de eliminerar splittrade sidor.
Det beror på följande; Om du lägger in en ny post i en tabell som har ett Clustrat Index som primärnyckel, och då denna nyckel ökar monotont, så innebär det att varje INSERT fysiskt sett kommer att hamna en efter en på hårddisken. Tack vare det så kommer det inte att ske några splittrade sidor, vilket i sig kommer att spara arbetslast. Det här beror på att SQL Server har förmågan att avgöra om de data som läggs in i en tabell har en monoton ökningssekvens, och då kommer det inte att bli några splittrade sidor då detta sker.
Om du lägger in flera poster på en gång (en tabell utan något Clustrat Index) så kommer inte posterna att läggas i någon specifik ordning på datasidorna, oavsett om dina data ökar monotont eller inte. Det resulterar i att din SQL Server måste arbeta hårdare (mer läsning) för att kunna accessa data som söks från hårddisken. Om å andra sidan ett Clustrat Index läggs in i tabellen så kommer alla data att lagras sekventiellt på datasidorna, och generellt sett så krävs det mindre I/O att hämta data när man söker det från hårddisken.
Om data läggs in i ett Clustrat Index i mer eller mindre blandad ordning så läggs det också in blandat på datasidorna, vilket liknar problemet med att lägga in mycket data på en gång – det bidrar till splittrade sidor.
Så än en gång är den bästa rekommendationen att lägga in ett Clustrat Index på en kolumn vars värden ökar monotont (förutsatt att det finns en kolumn som gör det) för att få bäst prestanda. Det gäller speciellt om en tabell utsätts för många INSERTs, UPDATEs eller DELETEs. Men om en tabell inte utsätts för så många datamodifikationer utan istället utsätts för en hel del SELECTs, så är den här rekommendationen mindre användbar och du bör istället överväga andra alternativ vid Clustrade Index. Läs de andra tipsen i den här artikeln för att få reda på de situationer där du bör skapa Clustrade Index på andra kolumner. [SQL Server 7.0, 2000] Uppdaterad 02-06-03.
*****
Eftersom du bara kan skapa ett Clustrat Index per tabell så bör du ta lite extra tid för att tänka igenom hur du ska använda det. Se över vilken typ av SQL-satser som ska köras mot din tabell och gör sedan en välriktad gissning om vilken SQL-sats (kanske den vanligaste som körs mot tabellen i fråga) som är den mest kritiska, och om den här SQL-satsen skulle kunna dra någon fördel av att ha ett Clustrat Index. [SQL Server 6.5, 7.0, 2000]
*****
Clustrade Index kan vara användbara för SQL-satser som möter följande specifikationer:
- För SQL-satser där du väljer ut data från en stor mängd värden, eller där du måste ha sorterade resultat. Det beror på att värdena redan är försorterade i Indexet åt dig. Exempel på det här är då du använder dig utav BETWEEN, <, >, GROUP BY, ORDER BY, och då du minskar ner data med hjälp av MAX, MIN och COUNT i dina SQL-satser.
- För SQL-satser som letar upp en post med ett unikt värde (såsom anställningsnummer) och då du behöver hämta ut de flesta eller alla data från det recordet. Det beror på att SQL-satsen täcks av Indexet. Med andra ord så finns de data du behöver i själva Indexet, och SQL Server behöver då inte läsa några extra sidor för att hämta tillbaka de data du har valt ut.
- För SQL-satser som accessar kolumner med ett begränsat antal distinkta värden, som t ex kolumner som innehåller land- eller ländata. Men om kolumnen innehåller få distinkta värden, som kolumner med t ex Ja/Nej eller Kvinna/Man, så bör dessa kolumner inte Indexeras alls.
- För SQL-satser som innehåller JOIN eller GROUP BY klausuler.
- För SQL-satser som returnerar väldigt många poster, och inte bara några stycken. Det beror än en gång på att de data som du behöver finns i Indexet, och behöver inte letas upp någon annanstans.
[SQL Server 6.5, 7.0, 2000]
*****
Om du stöter på en situation där du behöver ett enda brett Index (ett Kombinerat Index med tre eller flera kolumner) i en tabell, och då resterande Index i den här tabellen (förutsatt att det finns två eller fler) bara kommer att vara en kolumn breda, då bör du överväga att göra det breda Indexet som ett Clustrat Index och de resterande Indexen som icke-Clustrade Index.
Varför då? Om det breda Indexet är ett Clustrat Index så innebär det att hela tabellen är själva Indexet, och det krävs inte så mycket extra diskutrymme när du skapar Indexet. Om det breda Indexet däremot skulle vara ett icke-Clustrat Index så skulle det innebära att SQL Servern måste skapa ett ”relativt stort” Index, vilket definitivt skulle ta upp en hel del extra diskutrymme. När Indexet behöver användas av Query Processorn så skulle det vara effektivare att accessa det Clustrade Indexet istället för det icke-Clustrade Indexet, och prestandan skulle bli bättre. [SQL Server 6.5, 7.0, 2000] Inlagd 01-02-22.
*****
Undvik Clustrade Index på kolumner som redan är ”täckta” av icke-Clustrade Index. Det är onödigt att ha ett Clustrat Index på kolumner som redan är ”täckta”. Använd istället Clustrade Index på kolumner som kan dra mer nytta av det. [SQL Server 6.5, 7.0, 2000]
*****
När du väljer en kolumn som du ska basera ett Clustrat Index på så bör du försöka undvika kolumner som uppdateras ofta. Varje gång som en kolumn i ett Clustrat Index modifieras så måste alla icke-Clustrade Index också uppdateras, vilket skapar extra arbetslast. [SQL Server 6.5, 7.0, 2000] Inlagd 00-10-19.
*****
När du väljer den kolumnen (eller de kolumnerna) som ska inkluderas i ett Clustrat Index, så välj den kolumnen (eller för den första kolumnen i ett kombinerat Index) som innehåller de data som mest kommer att sökas efter i dina SQL-satser. [SQL Server 6.5, 7.0, 2000] Inlagd 01-01-19.
*****
Om en tabell har både ett Clustrat Index och icke-Clustrade Index så kommer prestandan att bli bäst optimerad om det Clustrade Indexet baseras på en enda kolumn som är så smal som möjligt. Det beror på att de icke-Clustrade Indexen använder sig av det Clustrade Indexet för att lokalisera dataposterna, och för att de icke-Clustrade Indexen måste hålla de Clustrade nycklarna inom deras B-träd struktur. Det här reducerar inte bara storleken på det Clustrade Indexet, utan även på alla de andra icke-Clustrade Indexen i tabellen också. [SQL Server 6.5, 7.0, 2000]
*****
Den primärnyckel som du har valt för tabellen bör inte alltid vara ett Clustrat Index. Men om du skapar en primärnyckel och inte anger något annat så är det standard. Gör bara primärnyckeln till ett Clustrat Index om du regelbundet kommer att utföra frågningar mot primärnyckeln eller om du behöver ha resultaten sorterade efter primärnyckeln. [SQL Server 6.5, 7.0, 2000]
*****
Om du tar bort eller ändrar ett Clustrat Index så måste du komma ihåg att alla icke-Clustrade Index också måste byggas om. Kom också ihåg att om du vill skapa om ett nytt Clustrat Index så måste du ha en fri diskyta på 1,2 gånger storleken på den tabell du arbetar med. Den här diskytan behövs för att kunna återskapa hela tabellen, medan den håller kvar den gamla tabellen tills den nya är återskapad. Sedan tas den gamla tabellen bort. [SQL Server 6.5, 7.0, 2000]
*****
När du ska avgöra om du vill ha ett Clustrat eller icke-Clustrat Index så kan det ibland hjälpa att veta ungefär hur stort det Clustrade Indexet kommer att bli. [SQL Server 7.0, 2000]
*****
Clustrade Indexvärdet upprepas många gånger i tabellens icke-Clustrade lagringsstruktur, och ett stort Clustrat Indexvärde kan onödigt öka den fysiska storleken på det Clustrade Indexet. På grund av det så är idealet att det Clustrade Indexet bör baseras på en enda kolumn (inte flera) som är så smal som möjligt. Det reducerar det Clustrade Indexets fysiska storlek och höjer prestandan. [SQL Server 6.5, 7.0, 2000] Inlagd 00-10-05.
*****
När du skapar ett Clustrat Index så bör du försöka att skapa det som ett UNIQUE (unikt) Clustrat Index, och inte som ett icke-unikt Clustrat Index. Det beror på att trots att SQL Server låter dig skapa ett icke-unikt Clustrat Index så kommer SQL Server (under ytan) att göra den unik åt dig, genom att lägga till ett 4-bytes ”uniqueifer” till Indexnyckeln för att garantera unikhet. Det enda du får då är en storleksökning på nyckeln, vilket ökar disk I/O, vilket i sin tur drar ner på prestandan. Om du när du skapar det Clustrade Indexet specificerar att det ska vara UNIQUE så kan du förhindra den extra onödiga arbetslasten. [SQL Server 7.0, 2000] Inlagd 00-10-19.
*****
Om det är möjligt så bör du undvika att skapa ett Clustrat Index på en GUID kolumn (datatypen uniqueidentifier). GUIDs tar upp 16 bytes lagringsutrymme, mer än en Identify kolumn, vilket gör Indexet större och ökar I/O läsningar, vilket skadar prestandan. Trots att prestandaförlusten är minimal om du skulle välja att skapa ett Clustrat Index på en GUID kolumn, så kommer varje liten bit att påverka. [SQL Server 7.0, 2000] Inlagd 02-02-08.
0 Kommentarer