Top vijf overwegingen voor het ontwerpen van database-indexen in SQL Server

Database-indexen worden gebruikt om verschillende tabelbewerkingen te versnellen. Voordat u een index maakt, is het echter belangrijk om te weten of u een index echt nodig heeft. En als u een index moet maken, wat zijn dan de belangrijke punten waarmee u rekening moet houden? Dit is waar het ontwerp van de database-index van pas komt.

Dit artikel is bedoeld om deze vragen over het ontwerpen van database-indexen te beantwoorden en enig licht te werpen op enkele van de belangrijkste overwegingen waarmee een databaseontwikkelaar rekening moet houden bij het ontwerpen van een index.

1. Tafelgrootte

De eerste vraag die een databaseontwikkelaar moet stellen voordat hij een index maakt, is of de tabel groot genoeg is om indexen efficiënt te gebruiken. Als de tabel klein is, kan de SQL Server-engine de volledige tabel sneller scannen dan de tabel te doorzoeken via een index. Indexen hebben in dat geval geen zin en creëren een overhead bij het uitvoeren van databasebewerkingen.

2. Kolomtypen

Indexen moeten worden gemaakt op een primaire sleutelkolom of een kolom die unieke waarden bevat en die een NOT NULL-beperking heeft. Verder is het raadzaam om indexen op numerieke kolommen te maken, aangezien numerieke kolommen doorgaans meer unieke waarden hebben in vergelijking met niet-numerieke kolommen. Een slecht database-indexontwerp maakt gebruik van indexen op kolommen met een paar unieke items en kan resulteren in zeer tijdrovende zoekopdrachten.

Overweeg een tabel met de naam Patiënten die honderdduizenden records bevat. De tabel Patiënten zou een kolom met de naam "Gender" bevatten die slechts twee unieke waarden "Man" en "Vrouw" kan hebben. Als u een index maakt op de “Gender Column”, worden de records in oplopende of aflopende alfabetische volgorde gesorteerd.

Dus als u een miljoen records in de tabel Patiënten heeft en het aantal mannelijke en vrouwelijke patiënten is gelijk, in de index hebben de eerste half miljoen records het geslacht "Vrouwelijk" en het tweede half miljoen het geslacht "Man". Als u nu naar een vrouw wilt zoeken die op de 490.000e rij van de vrouwelijke records staat, moet de SQL Server Engine door 490.000 records scannen. Aan de andere kant, met unieke numerieke waarden kan het zoeken extreem snel zijn, aangezien SQL Server-indexen worden opgeslagen in de vorm van B + Trees, en dus kunnen numerieke waarden in de boomknooppunten databasebewerkingen versnellen.

3. Aantal indexen

Officieel kunt u voor elke databasetabel één geclusterde index en zoveel niet-geclusterde indexen maken als u wilt. Het is echter een goed database-indexontwerp om één geclusterde index te maken en slechts een beperkt aantal absoluut noodzakelijke niet-geclusterde indexen. Door te veel niet-geclusterde indexen te maken, kunnen Update- en Insert-bewerkingen worden vertraagd, omdat wanneer een record wordt bijgewerkt of ingevoegd en een kolomwaarde wordt gewijzigd, alle bijbehorende indexen moeten worden bijgewerkt.

Overweeg een scenario waarin we twee niet-geclusterde indexen hebben, de eerste index sorteert de records op leeftijd en de tweede index sorteert de records op zowel geslacht als leeftijd.

Hier is de eerste index:

En hier is de tweede:

Als een record met de leeftijd van 40 om de een of andere reden moet worden bijgewerkt naar de leeftijd van 15, dan moet de eerste index worden bijgewerkt om het record van de 7e positie (40) naar de tweede positie te verplaatsen om de index gesorteerd te houden. Op dezelfde manier wordt in de tweede index het record in de 4e index verplaatst naar de tweede index. Er moet veel herschikt worden. Daarom is het verstandig om het aantal indexen tot een minimum te beperken voor de kolommen die regelmatig worden bijgewerkt bij het nadenken over het ontwerp van database-indexen. Ook mag één kolom niet worden gebruikt in meerdere niet-geclusterde indexen.

4. Opslaglocatie van indexen

De opslaglocatie van een index kan van invloed zijn op de prestaties van de query's die de index gebruiken en maakt dus ook deel uit van een goed database-indexontwerp. Standaard wordt een geclusterde index opgeslagen in dezelfde bestandsgroep als de tabel waarop de index is gemaakt. Voor niet-geclusterde indexen kan de index worden opgeslagen in dezelfde bestandsgroep of in verschillende bestandsgroepen die meerdere schijfstations omspannen. De queryprestaties van niet-geclusterde indexen kunnen aanzienlijk worden verbeterd door niet-geclusterde indexen op meerdere schijfstations op te slaan. Dit komt omdat de invoer/uitvoerprestaties van de query worden verbeterd als gevolg van de verspreiding van de gegevens over verschillende delen van de schijf.

De standaardopslaglocatie van indexen kan ook worden gewijzigd door een waarde op te geven voor de optie FILLFACTOR. Aangezien indexen fysiek worden opgeslagen in de vorm van B+ Trees, worden de indexgegevens opgeslagen op bladpagina's. Met de optie FILLFACTOR kunt u het percentage van de pagina's op bladniveau instellen dat moet worden gevuld. Als u bijvoorbeeld de waarde van FILLFACTOR instelt op 70%, wordt slechts 70% van de totale ruimte van de pagina op bladniveau gevuld met indexgegevens. De resterende 30% blijft over voor automatische groei van indexgegevens in de toekomst.

5. Indextypen

Een andere uiterst belangrijke overweging bij het ontwerpen van database-indexen is het type index dat moet worden gebruikt. In een eerder artikel (voeg een link toe naar het artikel "Wanneer geclusterde of niet-geclusterde index gebruiken") heb ik het verschil uitgelegd tussen geclusterde en niet-geclusterde indexen. Ik heb ook uitgelegd wat ze zijn en hoe ze kunnen worden gebruikt. De beslissing om te kiezen voor een geclusterde of een niet-geclusterde index is cruciaal en moet zorgvuldig worden overwogen.

Houd rekening met de volgende punten wanneer u beslist welk indextype u kiest.

1. Gebruik geclusterde indexen voor de kolommen die worden gebruikt in SELECT/JOIN/GROUP BY/BETWEEN-query's.
2. Gebruik niet-geclusterde indexen voor kolommen waar u alleen waarden wilt ophalen uit die specifieke kolom en niet uit de andere kolommen van dezelfde rij. SELECT-query's die meerdere records ophalen met behulp van een niet-geclusterde index kunnen traag zijn omdat de SQL Server-engine eerst de kolomwaarden zoekt waarop de index is gemaakt en vervolgens de rijverwijzing voor de kolomwaarde gebruikt, de records uit werkelijke databasetabellen worden opgehaald .
3. Gebruik een niet-geclusterde index voor de kolommen die vaak INSERT- en UPDATE-bewerkingen ondergaan. Zorg ervoor dat u niet één kolom in meerdere niet-geclusterde indexen gebruikt, omdat dat de updatequery's kan vertragen. Geclusterde indexen kunnen traag zijn voor INSERT/UPDATE-bewerkingen omdat de volledige rij moet worden bijgewerkt in plaats van slechts één kolomwaarde, zoals het geval is bij niet-geclusterde indexen.
4. Omdat je maar één geclusterde index kunt maken, in het geval dat je meerdere indexen nodig hebt, gebruik dan niet-geclusterde indexen. Als schijfruimte echter een groot probleem is, moet u het aantal niet-geclusterde indexen tot een minimum beperken.

Andere overwegingen

Hoewel dit de vijf belangrijkste onderdelen van het ontwerp van database-indexen zijn, zijn ze niet alles. Het is belangrijk om de juiste volgorde van de kolommen in indexen te specificeren. Als vuistregel geldt dat de kolommen die worden gebruikt voor besluitvorming in WHERE-clausules, en voorwaarden zoals groter dan (>), kleiner dan (<) enz., vóór de kolommen moeten worden geplaatst die niet bij deze clausules betrokken zijn. In het geval van meerdere kolommen in de WHERE-clausule, moeten de meest onderscheidende kolomnamen het vroegst in de Index-definitie worden vermeld.

Afgezien van het ontwerp van de database-index, speelt het ontwerp van de query ook een belangrijke rol bij het efficiënte gebruik van het indexontwerp. Voor geoptimaliseerd indexonderhoud in plaats van het schrijven van meerdere query's die op een klein aantal rijen werken, moet u proberen minder query's te schrijven die van invloed zijn op grotere aantallen tabelrijen.

Conclusie

In dit artikel worden enkele van de belangrijkste overwegingen uitgelegd waarmee een databaseontwikkelaar rekening moet houden bij het kijken naar het ontwerp van database-indexen. Het artikel legt ook de grondgedachte achter deze overwegingen uit en bevat verdere suggesties om ervoor te zorgen dat uw database-indexontwerp efficiënt is.