Index clusterisé dans SQL Server

Je sais que lorsque nous créons une table dans SQL Server avec sa key primaire, un index cluster est automatiquement créé. Mais si je supprime une ligne de cette table, l'index cluster lié à cette ligne rest-t-il sur la table d'index ou est-il automatiquement supprimé? S'il n'est pas supprimé automatiquement, dois-je créer un travail pour rebuild et réorganiser les index? (est-ce la même chose pour mysql, oracle, etc?)

Les valeurs par défaut ne sont pas les mêmes pour Oracle ou MySQL. Chaque database a ses propres valeurs par défaut et ses caractéristiques spécifiques. Certains utilisent même le même terme pour différentes significations.

Oracle n'est pas défini par défaut sur un index clusterisé et dans Oracle, l'équivalent est une table organisée par index. Dans Oracle, la définition de CLUSTER est une structure qui peut stocker 2 tables ou plus et les ordonner de la même manière.

S'il n'est pas supprimé automatiquement, dois-je créer un travail pour rebuild et réorganiser les index?

La règle n ° 1 de la reconstruction des index – Mesurer, mesurer, mesurer. Prouver que la reconstruction a été bénéfique, sinon ne vous embêtez pas à le faire à nouveau, à less que les choses changent.

Une simple suppression (ou mille) n'est pas une raison automatique pour rebuild un index.

Si vous êtes sur le sharepoint rebuild un index, vous devez savoir (1) combien de blocs de données avant et après (2) les time d'access avant et après.

Il y a beaucoup de désinformation et de superstition concernant les reconstructions d'index en tant que pratique générale. Les index auxquels vous faites reference sont des structures B-Tree. Ils sont conçus pour être modulables, O (log N) access. Il n'y a aucune preuve que les index doivent être réorganisés par défaut. Chaque index est son propre animal. Les index B-tree atteignent un sharepoint stase (équilibre) après un certain time d'utilisation, et quand vous les reconstruisez vous les compactez (une bonne chose), mais ils finissent par dériver vers ce sharepoint stase. À less que je repère un problème de performances / IO autour de l'un d'entre eux, alors je le ferai manuellement au cas par cas.

Les deux plus grands avantages de la reconstruction:

  1. Plus dense regroupe datatables en less de blocs, ce qui améliore le cache et les E / S.
  2. Réorganise les index non clusterisés par datatables réelles accumulées. Si vos schémas d'access sont toujours séquentiels (y compris les insertions) alors cela ne pose généralement pas de problème, les blocs seront commandés.

Oracle et SQL Server sont de merveilleuses technologies. Rebuild des index sans preuve n'est pas bon pour un DBA professionnel.

Je sais que lorsque nous créons une table dans sqlserver avec sa key primaire, un index cluster est automatiquement créé.

Ceci n'est vrai que s'il s'agit des options par défaut ou si clustered est spécifié en tant que mot-key. Les keys primaires peuvent également être des index non clusterisés.

Mais si je supprime une ligne de cette table, l'index cluster lié à cette ligne rest-t-il sur la table d'index ou est-il supprimé automatiquement?

Si c'est vraiment un index clusterisé, alors l'index EST datatables de la table. Si vous supprimez quelque chose de la table, c'est parti. Il existe quelques fonctionnements internes, tels que les loggings fantômes, mais oui datatables ont disparu (du sharepoint vue de l'application).

S'il n'est pas supprimé automatiquement, dois-je créer un travail pour rebuild et réorganiser les index?

C'est, il y a aussi d'autres tâches de fond qui traitent de certaines fonctions "cachées". Finalement, vous aurez envie de réorganiser ou de rebuild vos index lorsque la fragmentation (interne ou externe) commence à devenir un problème. Cela dépendra d'autres variables, y compris la structure de la table, l'access, etc.

(est-ce la même chose pour mysql, oracle, etc?)

La question a été étiquetée SQL Server, donc je réponds à la balise SQL Server. C'est une question très large pour un seul article.