Quand dois-je reconstruire des index?
Quand dois-je reconstruire les index dans ma base de données relationnelle (SQL Server)?
Y a-t-il lieu de reconstruire régulièrement des index?
Au risque d'être beaucoup trop général dans ma réponse, je dirai que vous devez exécuter régulièrement un processus de maintenance d'index. Cependant, votre processus de maintenance d'index ne doit reconstruire/réorganiser que les index qui l'exigent spécifiquement.
Cela pose la question: quand un index doit-il être reconstruit ou réorganisé? Rolando en a bien parlé. Encore une fois, je risque d'être extrêmement large. Un index nécessite une maintenance lorsque le niveau de fragmentation affecte négativement les performances. Ce niveau de fragmentation peut varier en fonction de la taille et de la composition de l'indice.
Parlant de SQL Server, j'ai tendance à choisir une taille d'index et un niveau de fragmentation d'index à quel point je commence à effectuer la maintenance d'index. Si un index contient moins de 100 pages, je n'effectuerai aucune maintenance.
Si un index est entre 10% et 30% fragmenté, je vais REORGANIZE l'index et UPDATE les statistiques. Si un index est fragmenté à plus de 30%, je vais REBUILD l'index - sans UPDATE STATISTICS, car cela est pris en charge par le REBUILD. N'oubliez pas qu'une reconstruction ne met à jour que l'objet statistique directement associé à l'index. Les autres statistiques des colonnes devront être conservées séparément.
Cette réponse est vraiment un long chemin à dire: oui, vous devriez faire la maintenance de routine des index, mais uniquement sur les index qui en ont besoin.
Quand dois-je reconstruire les index dans ma base de données relationnelle (par exemple SQL Server)?
Vous devez reconstruire les index lorsqu'ils deviennent très fragmentés par des événements spéciaux. Par exemple, vous effectuez un chargement important et en masse de données dans une table indexée.
Y a-t-il lieu de reconstruire régulièrement les index?
Que se passe-t-il si vos index se fragmentent régulièrement en raison d'une activité régulière? Devriez-vous planifier des reconstructions régulières? À quelle fréquence devraient-ils courir?
Tom Kyte , dans ce fil classique Ask Tom , recommande:
Le délai entre les reconstructions d'index doit être approximativement FOREVER.
...
Je ne sais pas comment le dire mieux - l'index veut être gros et gros avec plus d'espace. C'est sur une colonne que vous mettez à jour - déplacer l'entrée d'index d'un endroit à l'autre dans l'index. Un jour, la ligne a un code "A", le lendemain, le code est "G", puis "Z" puis "H" et ainsi de suite. Ainsi, l'entrée d'index pour la ligne se déplace d'un endroit à l'autre dans l'index. Ce faisant, il a besoin d'espace - si l'espace n'est pas là, nous divisons le bloc en deux - et faisons de l'espace. Maintenant, l'indice grossit. Au fil du temps, l'index est de 2 à 3 fois la taille qu'il était lorsque vous avez commencé et il est "à moitié ou plus vide". Maintenant, lorsque nous déplaçons les rangées, nous n'avons plus à diviser les blocs pour faire de la place - la salle est déjà disponible.
Ensuite, vous venez et reconstruisez ou supprimez et recréez l'index (qui a les mêmes effets - juste la reconstruction est "plus sûre") n'a aucune chance de perdre l'index et peut être plus rapide car l'index peut être reconstruit par l'analyse de l'index existant au lieu d'analyser la table et de trier et de créer un nouvel index). Maintenant, tout cet espace de Nice a disparu. Nous recommençons le processus de division des blocs - nous ramenant là où nous avons commencé.
Vous n'avez pas économisé d'espace.
L'index est exactement comme il était.
Vous perdriez simplement votre temps à le reconstruire, provoquant ainsi la répétition de ce cercle vicieux.
La logique ici est saine, mais elle est biaisée par rapport à un profil de charge lourd en lecture.
Un index "gras" (c'est-à-dire un avec beaucoup de lacunes) garde en effet une bonne quantité de place pour les lignes nouvelles et déplacées, réduisant ainsi les fractionnements de page et gardant vos écritures rapides. Cependant, lorsque vous lisez à partir de cet indice de graisse, vous devrez lire plus de pages pour obtenir les mêmes données, car vous parcourez maintenant plus d'espace vide. Cela ralentit vos lectures.
Ainsi, dans les bases de données lourdes en lecture, vous souhaitez régulièrement reconstruire ou réorganiser vos index. (À quelle fréquence et dans quelles conditions? Matt M a déjà un réponse concrète à cette question.) Dans les bases de données qui connaissent une activité de lecture et d'écriture à peu près équivalente, ou dans les bases de données qui sont lourdes en écriture, vous êtes probablement nuire aux performances de votre base de données en reconstruisant régulièrement les index.
La plupart des gens les reconstruisent régulièrement afin de ne jamais les fragmenter. Le moment où vous devez les reconstruire dépend de la vitesse à laquelle ils sont fragmentés. Certains index devront être reconstruits souvent, d'autres pratiquement jamais. Découvrez le script le SQLFool mis en place qui gère beaucoup de choses pour vous.
Comme indiqué dans la réponse acceptée de Matt M, une règle d'or courante est que les index qui sont fragmentés à plus de 30% doivent être reconstruits.
Cette requête vous aidera à trouver le nombre d'index dont vous disposez qui sont fragmentés à plus de 30% (lorsque vous en avez, vous devez les reconstruire):
SELECT DB_NAME() AS DBName,
OBJECT_NAME(ind.object_id) AS TableName,
ind.name AS IndexName,
indexstats.index_type_desc AS IndexType,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages,
SUM(p.rows) AS Rows
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.indexes AS ind ON ( ind.object_id = indexstats.object_id
AND ind.index_id = indexstats.index_id)
INNER JOIN sys.partitions AS p ON ( ind.object_id = p.object_id
AND ind.index_id = p.index_id)
WHERE indexstats.avg_fragmentation_in_percent > 30
GROUP BY
OBJECT_NAME(ind.object_id),
ind.name,
indexstats.index_type_desc,
indexstats.avg_fragmentation_in_percent,
indexstats.fragment_count,
indexstats.avg_fragment_size_in_pages
ORDER BY indexstats.avg_fragmentation_in_percent DESC
Quand dois-je reconstruire des index?
Lorsque le pourcentage de fragmentation de l'indice est supérieur à 30%.
Y a-t-il lieu de reconstruire régulièrement des index?
Il n'y a pas un tel cas, mais en général, faire la maintenance d'index une fois par semaine, le week-end est la meilleure pratique pour maintenir l'environnement stable.
Je recommanderais d'utiliser des scripts de maintenance d'Ola Hallengren (meilleurs scripts de maintenance), de personnaliser les scripts en fonction de votre environnement et de les planifier pour s'exécuter au cours du week-end.
Remarque: N'oubliez pas de mettre à jour les statistiques après la reconstruction des index, car la reconstruction des index ne met pas à jour toutes les statistiques.
Comme pour la plupart des choses en informatique, cela dépend. Quel problème essayez-vous de résoudre en reconstruisant les index? Pouvez-vous montrer qu'il résout réellement le problème? Si c'est le cas, ajustez les chiffres jusqu'à ce que vous trouviez le moins d'entretien que vous devez faire pour résoudre le problème.
Si cela ne résout pas le problème, ou si vous le faites, c'est simplement pour apaiser certaines mesures que vous surveillez car cela pourrait améliorer les choses, alors tout ce que vous faites est de graver le CPU et IO = et peut-être aggraver votre problème.
Il y a un argument selon lequel la correction de la fragmentation ne fera aucune différence pour votre serveur, alors cela vaut-il la peine de le faire régulièrement?
https://www.brentozar.com/archive/2017/12/index-maintenance-madness/