Quand devrais-je reconstruire les index?

Quand dois-je reconstruire les index dans ma base de données relationnelle (SQL Server)?

Est-il opportun de reconstruire les index régulièrement?

Au risque d’être trop général dans ma réponse, je dirai que vous devez exécuter un processus de maintenance d’index régulièrement. Cependant, votre processus de maintenance des index doit uniquement reconstruire / réorganiser les index qui en ont spécifiquement besoin.

Cela pose la question suivante: quand un index doit-il être reconstruit ou réorganisé? Rolando l'a bien dit. Encore une fois, je risque d’être extrêmement large. Un index nécessite une maintenance lorsque le niveau de fragmentation nuit aux performances. Ce niveau de fragmentation peut varier en fonction de la taille et de la composition de l’indice.

Parlant pour SQL Server, j’ai tendance à choisir une taille d’index et un niveau de fragmentation de l’index auquel je commence à effectuer la maintenance des index. Si un index contient moins de 100 pages, je n’effectue aucune maintenance.

Si un index est fragmenté entre 10% et 30%, je vais REORGANIZEl'index et UPDATEles statistiques. Si un index est fragmenté à plus de 30%, je le ferai REBUILD- sans UPDATE STATISTICS, car le fichier le prend en charge REBUILD. Rappelez-vous cependant qu'une reconstruction ne met à jour que l'objet de statistiques directement associé à l'index. Les autres statistiques de colonne devront être gérées séparément.

Cette réponse est vraiment juste un long chemin à dire: Oui, vous devriez faire la maintenance de routine des index, mais seulement 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 extrêmement fragmentés par des événements spéciaux. Par exemple, vous effectuez un important chargement en bloc de données dans une table indexée.

Est-il opportun de reconstruire les index régulièrement?

Alors, que se passe-t-il si vos index sont en train de se fragmenter régulièrement en raison d’une activité régulière? Devez-vous planifier des reconstructions régulières? À quelle fréquence doivent-ils courir?

Tom Kyte , dans ce fil classique Ask Tom , recommande:

Le délai entre les reconstructions d'index doit être d'environ FOREVER.

...

Je ne sais pas comment le dire mieux - l'indice veut être gros et gros avec un espace supplémentaire. 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 de "A", le lendemain, le code est "G", puis "Z", "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. Dans ce cas, il a besoin d'espace - si l'espace est insuffisant, nous divisons le bloc en deux - et faisons de l'espace. Maintenant, l'index devient gros. Au fil du temps, la taille de l'index est de 2 à 3 fois supérieure à celle que vous aviez au début et elle est "à moitié vide ou plus", mais vous pouvez déplacer les lignes. Désormais, lorsque nous déplaçons les rangées, nous n’avons plus besoin de diviser des blocs pour faire de la place: la salle est déjà disponible.

Ensuite, vous reconstruisez ou supprimez et recréez l’index (qui ont les mêmes effets (la reconstruction est simplement "plus sûre") - n’a aucune chance de perdre l’index et peut être plus rapide car l’index peut être reconstruit par analyse de l'index existant au lieu d'analyser la table et de trier et de créer un nouvel index). Maintenant, tout ce bel espace a disparu. Nous avons recommencé le processus de scission des blocs, ce qui nous a permis de retrouver le point de départ.

Vous avez économisé aucun espace.

L'index est exactement comme il était.

Vous perdriez simplement votre temps à le reconstruire, faisant que ce cercle vicieux se répète.

La logique ici est bonne, mais elle est biaisée contre un profil de charge lourd en lecture.

Un index "gras" (c’est-à-dire comportant beaucoup d’espaces vides) garde en effet une bonne quantité de place pour les nouvelles lignes et les lignes déplacées, réduisant ainsi le fractionnement des pages et préservant la rapidité de vos écritures. Cependant, lorsque vous lisez à partir de cet index de graisse, vous devez lire plus de pages pour obtenir les mêmes données, car vous parcourez maintenant davantage d'espace vide. Cela ralentit vos lectures.

Ainsi, dans les bases de données lues, vous souhaitez reconstruire ou réorganiser régulièrement vos index. (À quelle fréquence et dans quelles conditions? Matt M a déjà une réponse concrète à cette question.) Dans les bases de données dont l'activité en lecture et en écriture est à peu près équivalente, ou dans des bases de données très chargées en écriture, vous risquez de nuire aux performances de votre base de données en reconstruisant les index. régulièrement.

La plupart des gens les reconstruisent régulièrement afin qu'ils ne soient jamais fragmentés. Lorsque vous avez besoin de les reconstruire, cela dépend de la rapidité avec laquelle ils se fragmentent. Certains index devront être reconstitués souvent, d'autres en principe jamais. Consultez le script que SQLFool a mis en place et qui gère beaucoup de choses à comprendre pour vous.

Comme indiqué dans la réponse acceptée de Matt M, une règle commune est que les index fragmentés à plus de 30% doivent être reconstruits.

Cette requête vous aidera à trouver combien d'index sont fragmentés à plus de 30% (si 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 devrais-je reconstruire les index?

Lorsque le pourcentage de fragmentation de l'index est supérieur à 30%.

Est-il opportun de reconstruire les index régulièrement?

Cela n’existe pas, mais en général, la maintenance d’Index une fois par semaine au cours du week-end est la meilleure pratique pour préserver la stabilité de l’environnement.

Je recommanderais d'utiliser des scripts de maintenance de Ola Hallengren (meilleurs scripts de maintenance), de personnaliser les scripts en fonction de votre environnement et de les programmer pour qu'ils s'exécutent le week-end.

https://ola.hallengren.com/

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 avec la plupart des choses en informatique, cela dépend. Quel problème essayez-vous de résoudre en reconstruisant les index? Pouvez-vous montrer que cela résout réellement le problème? Si tel est le cas, modifiez les chiffres jusqu'à ce que vous trouviez le moins de maintenance possible pour résoudre le problème.

Si cela ne résout pas le problème ou si vous le faites uniquement pour apaiser une mesure que vous surveillez, car cela pourrait améliorer les choses, tout ce que vous faites est de brûler du processeur et des E / S, voire d'aggraver votre problème.

Certains prétendent que la résolution du problème ne fera aucune différence sur votre serveur. Cela vaut-il la peine de le faire régulièrement?

https://www.brentozar.com/archive/2017/12/index-maintenance-madness/

http://brentozar.com/go/defrag