Overzicht SQL Server-index
Als we het hebben over het afstemmen van SQL Server-prestaties en het verbeteren van query's, is het eerste dat u moet overwegen de SQL Server-index. Het dient om het lezen van gegevens uit onderliggende tabellen te versnellen door snelle toegang tot de gevraagde rijen te bieden. Het hoeft dus niet alle records van de tafel te scannen.
De SQL Server-index biedt die snelle zoekmogelijkheden dankzij de B-Tree-structuur van de index. Deze structuur maakt het mogelijk om snel door de tabelrijen te bladeren op basis van de indexsleutel en de gevraagde records in één keer op te halen. Het hoeft niet de hele tabel te lezen.
Typen SQL Server-indexen
Van de belangrijkste typen besteden we aandacht aan de geclusterde en niet-geclusterde indexen.
De geclusterde index sorteert de feitelijke gegevens op de gegevenspagina's volgens de geclusterde indexsleutelwaarden. Het slaat de gegevens op het 'blad'-niveau van de index op, waardoor het mogelijk is om slechts één geclusterde index op elke tabel te maken. De geclusterde index wordt automatisch gemaakt wanneer een beperking van de primaire sleutel op de heaptabel verschijnt.
De Niet-geclusterde index bevat de waarde van de indexsleutel en een verwijzing naar de rest van de rijkolommen in de hoofdtabel. Het is het 'blad'-niveau van de index, met de mogelijkheid om tot 999 niet-geclusterde indexen op elke tabel te creëren.
Als uw tabel geen geclusterde index heeft, wordt de tabel de 'Heap-tabel' genoemd. Een dergelijke tabel heeft geen criteria om de gegevensvolgorde binnen de pagina's en het sorteren en koppelen van de pagina's aan te geven.
Wanneer een geclusterde index op die tabel wordt gemaakt, noemen we de gesorteerde tabel een geclusterde tabel.
Er zijn ook andere soorten indexen die door SQL Server worden geleverd:
- De unieke index dwingt de uniciteit van de kolomwaarden af;
- De dekkingsindex bevat alle kolommen die door de zoekopdracht zijn gevraagd;
- De samengestelde index bevat meerdere kolommen in de indexsleutel;
- Andere specifieke indextypen zijn XML-, Spatial- en Columnstore-indexen.
Het voordeel van de SQL Server-index is dat het de prestaties van de query's verbetert. Het werkt echter als alleen de index correct is. Als u het verkeerd ontwerpt, heeft dit een negatieve invloed op de prestaties van de query's en verbruikt het de SQL Server-bronnen om nutteloze indexen op te slaan en te onderhouden.
Het kiezen van de beste index die alle problemen oplost, is geen gemakkelijke taak. Het toevoegen van een nieuwe index kan het proces voor het ophalen van gegevens versnellen, maar het vertraagt de processen voor het wijzigen van gegevens. Elke wijziging die in de onderliggende tabel wordt uitgevoerd, wordt rechtstreeks weergegeven in alle gerelateerde indexen om de gegevens consistent te houden.
Daarom moet u de impact van de nieuwe index bestuderen en testen voordat u deze in de productieomgeving maakt. Het is ook noodzakelijk om de impact en het gebruik ervan te monitoren nadat het in de productieomgeving is geïmplementeerd.
Te overwegen factoren bij het ontwerpen van een nieuwe SQL Server-index
De eerste factor is het type database-werkbelasting . Stel dat we te maken hebben met een OLTP-workload met een groot aantal schrijfbewerkingen. Het vereist zo min mogelijk indexen. Een ander geval is een OLAP-werklast met veel leesbewerkingen – er zijn zoveel mogelijk indexen nodig om het ophalen van gegevens te versnellen.
Je moet ook kijken naar de tafelgrootte . SQL Server Engine scant liever de onderliggende tabel rechtstreeks, in plaats van tijd en middelen te verspillen aan het kiezen van de beste index voor het ophalen van gegevens uit die kleine tabel.
Als u eenmaal heeft besloten een index voor die tabel te maken, moet u het indextype identificeren om uw zoekopdracht uit te voeren . Daar specificeert u de kolommen die aan de indexsleutel zijn toegevoegd. De bases zijn het gegevenstype en de positie van de kolom in de query-predikaten en join-voorwaarden.
Deze factoren moeten de beste prestaties voor het ophalen van gegevens garanderen, in de juiste volgorde, en de index zo kort en eenvoudig mogelijk houden.
Een andere factor waarmee u rekening moet houden bij het ontwerpen van een nieuwe index is de indexopslag . Het wordt aanbevolen om niet-geclusterde indexen te maken op een aparte bestandsgroep en schijf. Op deze manier isoleert u de I/O-bewerkingen die worden uitgevoerd in de indexgegevenspagina's van de databasegegevensbestanden.
Overweeg de index in te stellen FILLFACTOR , die het percentage ruimte bepaalt op elke pagina op bladniveau die is gevuld met gegevens (de waarde verschilt van de standaardwaarde 0 of 100 procent). Het doel is om op elke pagina met indexgegevens ruimte te laten voor de nieuw ingevoegde of bijgewerkte records. Het minimaliseert ook het voorkomen van paginasplitsingen die kunnen leiden tot het indexfragmentatieprobleem.
Indexbeheer
De rol van de databasebeheerder bij het verbeteren van de prestaties van de query's met SQL Server-indexen is niet beperkt tot het maken van de index. U moet het indexgebruik proactief controleren om de kwaliteit ervan te identificeren. Bovendien moeten we de index regelmatig onderhouden om de fragmentatieproblemen op te lossen.
SQL Server Management Studio, met zijn robuuste rapportagefunctionaliteit, biedt de meest bruikbare statistische gegevens aan de databasebeheerders. Een van deze ingebouwde rapporten is Indexgebruiksstatistieken :
Het rapport Indexgebruiksstatistieken beschrijft hoe database-indexen worden gebruikt in de vorm van:
- Zoekt :het aantal keren dat de index door SQL Engine wordt gebruikt om een specifieke rij te vinden.
- Scans :het aantal keren dat de indexbladpagina's worden gescand door de SQL Engine.
- Zoekopdrachten :het aantal keren dat een niet-geclusterde index is gebruikt als geclusterde index om de rest van de kolommen op te halen die niet in de niet-geclusterde index staan.
- Updates :het aantal keren dat de indexgegevens zijn gewijzigd.
Merk op dat het primaire doel van het maken van een index is om een indexzoekbewerking uit te voeren, zoals hieronder weergegeven:
Het vorige rapport helpt aanzienlijk bij het specificeren of de SQL Server gebruikmaakt van deze indexen om het proces voor het ophalen van gegevens te versnellen of niet. Als blijkt dat een bepaalde index niet naar behoren presteert, laat hem dan vallen en vervang hem door een betere.
Het tweede rapport van de SSMS is de Index Physical Statistics . Het retourneert de statistische informatie over het indexfragmentatiepercentage per indexpartitie, met het aantal pagina's op elke indexpartitie.
Het beveelt ook aan hoe de problemen met de indexfragmentatie kunnen worden opgelost door die index opnieuw op te bouwen of te reorganiseren volgens het fragmentatiepercentage, zoals hieronder weergegeven:
Om de aanbevelingen van het rapport toe te passen, kunt u de opdracht indexdefragmentatie voor elke index uitvoeren. Of u kunt een onderhoudsplan maken met SSMS om de index op de beste manier te onderhouden.
dbForge Indexmanager
dbForge Index Manager is een SSMS-invoegtoepassing die dient om de fragmentatieproblemen van SQL Server-indexen te detecteren en op te lossen.
Het is ook een gecentraliseerde tool die de mogelijkheid biedt om het indexfragmentatiepercentage in de databases te detecteren. U kunt deze problemen oplossen door een index opnieuw op te bouwen. Een andere manier is om de activiteiten te reorganiseren op basis van de mate van fragmentatie van die index. Naast andere opties is er het genereren van T-SQL-scripts voor het uitvoeren van indexgerelateerde opdrachten, het exporteren van de resultaten van de indexanalyse voor latere referentie en het gebruik van de opdrachtregelinterface om de onderhoudstaken voor de index te automatiseren.
dbForge Index Manager is beschikbaar op de Devart-downloadpagina. U kunt het op uw computer installeren met behulp van een eenvoudige installatiewizard. Na de succesvolle installatie is deze invoegtoepassing klaar voor gebruik.
Om het binnen de SSMS te gebruiken, klikt u met de rechtermuisknop op de database en kiest u Indexfragmentatie beheren uit de Index Manager-lijst:
Vanuit het Index Manager-venster kunt u de databasenaam filteren die u interesseert.
Klik op Heranalyseren om de indexfragmentatiecontrole uit te voeren voor de geselecteerde database. Het toont automatisch de indexfragmentatiestatistieken voor alle indexen die tijdens dit proces in de geselecteerde database zijn gemaakt.
De tool Index Manager beveelt ook de acties aan om de problemen met indexfragmentatie op te lossen, gebaseerd op het fragmentatiepercentage:
Door indexen te controleren onder de sectie Vereiste acties in het vorige venster, is het mogelijk om de lijst met acties te exporteren als een CSV-rapport. Hiermee kunt u de voorgestelde oplossing uitvoeren door problematische indexen rechtstreeks vanaf die pagina te reorganiseren of opnieuw te bouwen of een script te genereren om dit later te doen:
De fixatie van de indexfragmentatie in ons scenario is als volgt:
Als u het vorige script uitvoert of op de Fix . klikt optie, en dan Heranalyseren het resultaat, je ziet dat het fragmentatieprobleem direct is opgelost:
Op deze manier profiteren we van de dbForge Index Manager om de indexfragmentatieproblemen te analyseren en te identificeren en deze vervolgens rechtstreeks vanaf dezelfde plek te rapporteren of op te lossen.
Handig hulpmiddel
dbForge Index Manager brengt slimme indexfixatie en indexfragmentatie rechtstreeks in SSMS. Met de tool kunt u snel indexfragmentatiestatistieken verzamelen en databases detecteren die onderhoud nodig hebben. U kunt SQL Server-indexen direct opnieuw opbouwen en reorganiseren in de visuele modus of SQL-scripts genereren voor toekomstig gebruik. dbForge Index Manager voor SQL Server zal uw prestaties aanzienlijk verbeteren zonder veel moeite.