SQL-serverindexöversikt
När man talar om SQL Server-prestandajustering och förbättring av frågor är det första man bör tänka på SQL Server Index. Det tjänar till att påskynda läsning av data från underliggande tabeller genom att ge snabb åtkomst till de begärda raderna. Därför behöver den inte skanna alla tabellens poster.
SQL Server-indexet tillhandahåller de snabba sökmöjligheterna på grund av indexets B-Tree-struktur. Denna struktur gör det möjligt att snabbt gå igenom tabellraderna baserat på indexnyckeln och hämta de begärda posterna på en gång. Den behöver inte läsa hela tabellen.
SQL Server-indextyper
Bland huvudtyperna uppmärksammar vi de klustrade och icke-klustrade indexen.
Det klustrade indexet sorterar den faktiska datan på datasidorna enligt de klustrade indexnyckelvärdena. Den lagrar data på "blad"-nivå av indexet, vilket säkerställer möjligheten att skapa endast ett klustrade index på varje tabell. Det klustrade indexet skapas automatiskt när en primärnyckelbegränsning visas i heaptabellen.
Det icke-klustrade indexet innehåller indexnyckelvärdet och en pekare till resten av radkolumnerna i huvudtabellen. Det är "blad"-nivån för indexet, med möjlighet att skapa upp till 999 icke-klustrade index på varje tabell.
Om din tabell inte har något klustrat index skapat på sig kallas tabellen "Högtabell". En sådan tabell har inga kriterier för att specificera dataordningen inuti sidorna och sidornas sortering och länkning.
När ett klustrat index skapas på den tabellen kallar vi den sorterade tabellen för en klustrad tabell.
Det finns andra typer av index som tillhandahålls av SQL Server också:
- Det unika indexet tvingar fram kolumnvärdenas unikhet;
- Det täckande indexet innehåller alla kolumner som begärs av frågan;
- Det sammansatta indexet innehåller flera kolumner i indexnyckeln;
- Andra särskilda indextyper är XML-, Spatial- och Columnstore-index.
Fördelen med SQL Server-index är att det förbättrar frågornas prestanda. Det fungerar dock om bara indexet är korrekt. Skulle du designa fel på det kommer det att påverka frågornas prestanda negativt och förbruka SQL Server-resurserna för att lagra och underhålla värdelösa index.
Att välja det bästa indexet som löser alla problem är inte en lätt uppgift. Att lägga till ett nytt index kan påskynda datahämtningsprocessen, men det saktar ner datamodifieringsprocesserna. Varje förändring som görs av den underliggande tabellen getы reflekteras direkt till alla relaterade index för att hålla data konsekvent.
Det är därför du bör studera och testa det nya indexets inverkan innan du skapar det i produktionsmiljön. Det är också nödvändigt att övervaka dess inverkan och användning efter att ha distribuerats till produktionsmiljön.
Faktorer att tänka på när man designar ett nytt SQL Server-index
Den första faktorn är databas arbetsbelastningstyp . Anta att vi hanterar en OLTP-arbetsbelastning med ett stort antal skrivoperationer. Det kräver minsta möjliga antal index. Ett annat fall är en OLAP-arbetsbelastning med många läsoperationer – det kommer att kräva så många index som möjligt för att påskynda datahämtningen.
Du måste också titta på tabellstorleken . SQL Server Engine föredrar att skanna den underliggande tabellen direkt, istället för att slösa tid och resurser på att välja det bästa indexet för datahämtning från den lilla tabellen.
När du har bestämt dig för att skapa ett index på den tabellen måste du identifiera indextypen för att betjäna din fråga . Där anger du de kolumner som lagts till i indexnyckeln. Baserna är kolumndatatypen och positionen i frågepredikaten och sammanfogningsvillkoren.
Dessa faktorer bör garantera bästa prestanda för datahämtning, i rätt ordning, och hålla indexet så kort och enkelt som möjligt.
En annan faktor att tänka på när du designar ett nytt index är indexlagringen . Det rekommenderas att skapa icke-klustrade index på en separat filgrupp och diskenhet. På så sätt isolerar du I/O-operationerna som utförs på indexdatasidorna från databasdatafilerna.
Överväg att ställa in index FILLFACTOR , som bestämmer procentandelen utrymme på varje bladnivåsida fylld med data (värdet skiljer sig från standardvärdet 0 eller 100 procent). Målet är att lämna utrymme på varje indexdatasida för de nyligen infogade eller uppdaterade posterna. Det minimerar också förekomsten av siddelning som kan leda till indexfragmenteringsproblemet.
Indexhantering
Databasadministratörens roll i att förbättra frågornas prestanda med SQL Server-index är inte begränsad till att skapa indexet. Du bör proaktivt övervaka indexanvändningen för att identifiera dess kvalitet. Dessutom måste vi underhålla indexet regelbundet för att åtgärda fragmenteringsproblemen.
SQL Server Management Studio, med sin robusta rapporteringsfunktionalitet, tillhandahåller de mest användbara statistikdata till databasadministratörerna. En av dessa inbyggda rapporter är Indexanvändningsstatistik :
Rapporten Indexanvändningsstatistik beskriver hur databasindex används i form av:
- Sök :antalet gånger indexet används av SQL Engine för att hitta en specifik rad.
- Sökningar :antalet gånger indexbladssidorna skannas av SQL Engine.
- Sökningar :antalet gånger som ett icke-klustrat index användes som ett klustrat index för att hämta resten av kolumnerna som inte är listade i det icke-klustrade indexet.
- Uppdateringar :antalet gånger som indexdata har ändrats.
Observera att det primära syftet med att skapa index är att utföra en indexsökning, som visas nedan:
Den tidigare rapporten hjälper avsevärt att specificera om SQL Server drar fördel av dessa index för att påskynda datahämtningsprocessen eller inte. Om det visar sig att ett visst index inte fungerar som det ska, släpp det och ersätt det med ett bättre.
Den andra rapporten som tillhandahålls av SSMS är Index Physical Statistics . Den returnerar statistisk information om indexfragmenteringsprocenten för varje indexpartition, med antalet sidor på varje indexpartition.
Den rekommenderar också hur du åtgärdar indexfragmenteringsproblemen genom att bygga om eller omorganisera det indexet, enligt fragmenteringsprocenten, som visas nedan:
För att tillämpa rekommendationerna i rapporten kan du köra kommandot indexdefragmentering för varje index. Eller så kan du skapa en underhållsplan med SSMS för att underhålla indexet på bästa sätt.
dbForge Index Manager
dbForge Index Manager är ett SSMS-tillägg som tjänar till att upptäcka och åtgärda problem med fragmentering av SQL Server-index.
Det är också ett centraliserat verktyg som ger möjlighet att upptäcka indexfragmenteringsprocenten över databaserna. Du kan åtgärda dessa problem genom att utföra en indexombyggnad. Ett annat sätt är att omorganisera verksamheten, baserat på fragmenteringsgraden av det indexet. Bland andra alternativ finns generering av T-SQL-skript för exekvering av indexrelaterade kommandon, export av indexanalysresultat för senare referens och användning av kommandoradsgränssnittet för att automatisera indexunderhållsuppgifterna.
dbForge Index Manager är tillgänglig på nedladdningssidan för Devart. Du kan installera den på din maskin med hjälp av en enkel installationsguide. Efter den lyckade installationen är detta tillägg klart för användning.
För att använda den inom SSMS, högerklicka på databasen och välj Hantera indexfragmentering från Indexhanteraren:
Från Indexhanterarens fönster kan du filtrera databasnamnet som intresserar dig.
Klicka på Analysera om för att utföra indexfragmenteringskontrollen för den valda databasen. Den visar automatiskt indexfragmenteringsstatistiken för alla index som skapats under den valda databasen under denna process.
Indexhanteraren rekommenderar också åtgärder för att åtgärda indexfragmenteringsproblemen, baserat på fragmenteringsprocenten:
Att kontrollera index under avsnittet Åtgärder som krävs i föregående fönster gör det möjligt att exportera åtgärdslistan som en CSV-rapport. Det låter dig utföra den föreslagna korrigeringen genom att omorganisera eller bygga om problematiska index direkt från den sidan eller generera ett skript för att göra det senare:
Indexfragmenteringskorrigeringen i vårt scenario kommer att vara enligt nedan:
Om du kör det föregående skriptet eller klickar på Fix alternativet och sedan Analysera om resultatet ser du att fragmenteringsproblemet är åtgärdat direkt:
På så sätt drar vi nytta av dbForge Index Manager för att analysera och identifiera indexfragmenteringsproblem och sedan rapportera eller åtgärda dem direkt från samma plats.
Användbart verktyg
dbForge Index Manager ger smart indexfixering och indexfragmentering direkt in i SSMS. Verktyget låter dig snabbt samla in indexfragmenteringsstatistik och upptäcka databaser som kräver underhåll. Du kan omedelbart bygga om och omorganisera SQL Server-index i visuellt läge eller generera SQL-skript för framtida bruk. dbForge Index Manager för SQL Server kommer att öka din prestanda avsevärt utan större ansträngning.