Over het algemeen zou mijn indexeringsstrategie ongeveer als volgt zijn (ik gebruik voorlopig uitsluitend SQL Server - pas indien nodig aan aan uw eigen databasesysteem):
-
kies een goede clustersleutel - geen GUID, geen
VARCHAR(250)of zoiets - een goede clustersleutel is smal, uniek, stabiel, steeds groter - zoiets als eenINT IDENTITYis perfect. Maakt dit uw geclusterde primaire sleutel -> geeft u uw eerste index op de tafel -
voor elke kolom die wordt gebruikt als een externe sleutel in een andere tabel - voeg een index toe. Het kan een index met één kolom zijn - of het kan een samengestelde index zijn - wat het beste werkt voor uw geval. Het is belangrijk dat de kolom met de refererende sleutel de eerste . is kolom in die index (als u een samengestelde index gebruikt) - anders zijn de voordelen voor de
JOIN's of voor het controleren van referentiële integriteit is niet beschikbaar voor uw systeem
En dat was het voor nu.
Vervolgens:voer uw systeem uit - observeer en meet - stel een basislijn vast. Is de app snel genoeg? Zo ja -> je bent klaar - ga naar huis en geniet van je vrije tijd.
Zo niet:begin dan met het verzamelen van data en indicaties waarom de app niet snel genoeg is. Kijk naar bijv. dingen zoals de DMV's in SQL Server die u vertellen over de slechtst presterende query's, of de ontbrekende index DMV . Analyseer die. Kijk wat je zou kunnen verbeteren. Voeg één index per keer toe en nogmaals:observeren, meten, vergelijken met je baseline.
Als je verbetering hebt -> laat die index staan en deze meting is je nieuwe baseline. Spoel en herhaal totdat u (en uw gebruikers) tevreden zijn met de prestaties van de app (en daarna ga naar huis en geniet van je vrije tijd).
Overindexering in SQL Server kan erger zijn dan geen indexen hebben. Begin niet met te veel indices om mee te beginnen! Stel alleen goed vast geclusterde PK en niet-geclusterde indices met buitenlandse sleutels - dat is alles - observeer, meet, optimaliseer en herhaal die cyclus.