Pourquoi devons-nous reconstruire et réorganiser les index dans SQL Server


28

Après avoir cherché sur Internet, je n'ai pas trouvé la raison de

  1. Pourquoi devons-nous reconstruire et réorganiser les index dans SQL Server?

  2. que se passe-t-il en interne lorsque nous reconstruisons et réorganisons?

Un article sur un site dit:

L'index doit être reconstruit lorsque la fragmentation de l'index est supérieure à 40%. L'indice doit être réorganisé lorsque la fragmentation de l'indice se situe entre 10% et 40%. Le processus de reconstruction d'index utilise plus de CPU et il verrouille les ressources de la base de données. La version de développement SQL Server et la version Enterprise ont l'option ONLINE, qui peut être activée lors de la reconstruction de l'index. L'option EN LIGNE gardera l'index disponible pendant la reconstruction.

Je ne pouvais pas comprendre cela, même si cela dit WHENcela, mais j'aimerais savoir WHYsi nous devons reconstruire et réorganiser les index?


1
C'est la question de savoir pourquoi, et voici la question de quand .
Nick Chammas

Réponses:


29

Au fur et à mesure que vous effectuez des insertions de mises à jour et de suppressions, vos index seront fragmentés à la fois en interne et en externe.

La fragmentation interne est que vous disposez d'un pourcentage élevé d'espace libre sur vos pages d'index, ce qui signifie que SQL Server doit lire plus de pages lors de l'analyse de l'index.

La fragmentation externe se produit lorsque les pages de l'index ne sont plus en ordre, donc SQL Server doit faire plus de travail, en particulier en termes d'E / S pour lire l'index.

Si vos index deviennent trop fragmentés, au mieux, vos requêtes seront moins efficaces, mais au pire, SQL Server cessera simplement d'utiliser les index tous ensemble, ce qui signifie que pratiquement toutes les requêtes devront effectuer une analyse de table ou une analyse d'index en cluster. Cela nuira beaucoup à vos performances!

Lorsque vous réorganisez un index, SQL Server utilise les pages d'index existantes et mélange simplement les données sur ces âges. Cela atténuera la fragmentation interne et peut également supprimer une petite quantité de fragmentation externe. C'est une opération plus légère que la reconstruction et est toujours en ligne.

Lorsque vous reconstruisez un index, SQL Server recueille en fait les données de l'index et utilise un nouvel ensemble de pages d'index. Cela atténuera évidemment la fragmentation interne et externe, mais c'est une opération plus lourde et par défaut entraîne la mise hors ligne de l'index, bien qu'il puisse être effectué en tant qu'opération en ligne, selon votre version et vos paramètres SQL Server.

Cependant, ne vous attendez pas à avoir 0 fragmentation après une reconstruction. À moins que vous n'utilisiez un indice de requête MAXDOP, SQL Server parallélisera l'opération de reconstruction et plus il y aura de processeurs impliqués, plus il y aura probablement de fragmentation, car chaque processeur ou noyau reconstruira sa section ou fragment d'index individuellement, sans tenir compte de L'un et l'autre. Il s'agit d'un compromis entre les meilleurs niveaux de fragmentation et le temps nécessaire pour reconstruire l'indice. Pour une fragmentation proche de 0, utilisez MAXDOP 1 et triez les résultats dans TempDB.


Génial...! Explique simplement ...!
DineshDB

0

Afin de supprimer la fragmentation qui provoque des problèmes tels que la lenteur au niveau de la base de données / les requêtes longues, etc.

Pour obtenir une compréhension détaillée de la fragmentation et du fonctionnement de la reconstruction et de la réorganisation des index (ou de la réorganisation des pages d'index), reportez-vous au lien ci-dessous: https://www.idera.com/productssolutions/sqlserver/sqldefragmanager/what-is-fragmentation


1
Ces informations sont devenues (en partie) obsolètes après avoir consulté Pourquoi la fragmentation de l'index n'a pas d'importance
John aka hot2use
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.