Mise à jour
Ceci est maintenant implémenté dans SQL Server Azure. Il génère des recommandations
et la gestion des index peut être configurée pour être automatique .
Activer la gestion automatique des index
Vous pouvez configurer le Conseiller de base de données SQL pour qu'il implémente les recommandations automatiquement. Au fur et à mesure que les recommandations deviennent disponibles, elles seront automatiquement appliquées. Comme pour toutes les opérations d'index gérées par le service, si l'impact sur les performances est négatif, la recommandation est annulée.
Réponse originale
Certaines bases de données créent déjà (en quelque sorte) des index automatiquement.
Dans SQL Server, le plan d'exécution peut parfois inclure un opérateur de spool d'index dans lequel le SGBDR crée dynamiquement une copie indexée des données. Cependant, ce spool n'est pas une partie persistante de la base de données maintenue synchronisée avec les données source et ne peut pas être partagé entre les exécutions de requêtes, ce qui signifie que l'exécution de tels plans peut aboutir à la création et à la suppression répétées d'index temporaires sur les mêmes données.
Peut-être qu'à l'avenir, les SGBDR auront la capacité de supprimer et de créer dynamiquement des index persistants en fonction de la charge de travail.
Le processus d’optimisation des indices n’est finalement qu’une analyse coûts-avantages. S'il est vrai que les utilisateurs peuvent avoir davantage d'informations sur l'importance relative des requêtes dans une charge de travail, il n'y a en principe aucune raison pour que ces informations ne puissent pas être mises à la disposition de l'optimiseur. SQL Server dispose déjà d'un gouverneur de ressources permettant de classer les sessions en différents groupes de charges de travail avec différentes allocations de ressources, en fonction de leur priorité.
Les DMV d'index manquants mentionnés par Kenneth ne sont pas conçus pour être implémentés à l'aveugle, car ils ne considèrent que les avantages d'une requête spécifique et ne tentent pas de prendre en compte le coût de l'index potentiel par rapport à d'autres requêtes. Il ne consolide pas non plus les index manquants similaires. par exemple, la sortie de ce fichier DMV peut signaler des index manquants sur A,B,CetA,B INCLUDE(C)
Certains problèmes actuels avec l'idée sont
- La qualité de toute analyse automatisée qui ne crée pas réellement l'indice dépendra beaucoup de la précision du modèle de calcul des coûts.
- Même dans le domaine de l'analyse automatisée, une solution hors ligne pourra être plus complète qu'une solution en ligne, car il est impératif qu'une solution en ligne n'augmente pas les frais de gestion de la comptabilité pour le serveur actif et interfère avec son objectif principal d'exécution de requêtes.
- Les index créés automatiquement en réponse à une charge de travail seront nécessairement créés en réponse à des requêtes qui les auraient trouvées utiles, de sorte qu'ils seront en retard sur les solutions qui créent les index à l'avance.
Il est probablement raisonnable de s'attendre à ce que la précision des modèles d'établissement des coûts s'améliore avec le temps, mais le point 2 semble plus difficile à résoudre et le point 3 est intrinsèquement insoluble.
Néanmoins, la grande majorité des installations ne sont probablement pas dans cette situation idéalisée avec un personnel qualifié qui surveille, diagnostique et anticipe en permanence (ou du moins réagit aux) changements de charge de travail.
Le projet AutoAdmin de Microsoft Research est en cours depuis 1996
Le but de ce projet est de rendre les bases de données auto-ajustables et auto-administrables en exploitant la connaissance de la charge de travail
La page d'accueil du projet répertorie plusieurs projets intrigants. L'une est particulièrement pertinente pour la question ici
Un autre problème intéressant se pose lorsqu'il n'y a pas de DBA disponible (par exemple, une base de données intégrée ou une petite entreprise). Dans de tels scénarios, une approche de réglage continu de l’indice sans contact peut devenir importante. Nous avons exploré des solutions ... [en] “ Une approche en ligne du réglage de la conception physique ” dans ICDE 2007.
Les auteurs déclarent
Avec des fonctionnalités de SGBD de plus en plus courantes telles que les index en ligne, il est intéressant d’explorer des solutions plus automatiques au problème de conception physique qui fait progresser l’état de la technique.
Le papier introduit un algorithme
Ses principales caractéristiques sont:
- Au fur et à mesure que les requêtes sont optimisées, nous identifions un ensemble pertinent d'index candidats susceptibles d'améliorer les performances. Cette fonctionnalité permet au traitement des requêtes de continuer en parallèle avec les index construits en arrière-plan.
- Au moment de l'exécution, nous suivons les avantages potentiels que nous perdons en ne disposant pas de tels index candidats, ainsi que l'utilité des index existants en présence de requêtes, de mises à jour et de contraintes d'espace.
- Une fois que nous avons rassemblé suffisamment de «preuves» selon lesquelles une modification de la conception physique est bénéfique, nous déclenchons automatiquement la création ou la suppression d'index.
- La nature en ligne de notre problème implique que nous allons généralement prendre du retard par rapport aux solutions optimales qui connaissent l'avenir. Cependant, en mesurant avec soin les éléments de preuve, nous nous assurons de ne pas souffrir de décisions «tardives», ce qui limite le montant des pertes subies.
L'implémentation de l'algorithme permet une limitation en réponse aux modifications de la charge du serveur et peut également interrompre la création d'index si, au cours de la création, les modifications de charge de travail et les avantages attendus deviennent inférieurs au seuil jugé intéressant.
La conclusion des auteurs sur le thème de l' optimisation physique en ligne versus traditionnelle.
Les algorithmes en ligne utilisés dans ce travail sont utiles lorsque les administrateurs de base de données ont des doutes sur le comportement futur de la charge de travail ou n'ont aucune possibilité d'effectuer une analyse ou une modélisation complète. Si un administrateur de base de données dispose de toutes les informations sur les caractéristiques de la charge de travail, une analyse statique et le déploiement à l'aide d'outils existants (par exemple, [2, 3]) constitueraient une meilleure alternative.
Les conclusions ici sont similaires à celles d'un autre article . Réglage d'index piloté par une requête autonome
Notre approche ne peut pas battre le conseiller indiciel si l’ensemble de la charge de travail est connue à l’avance. Toutefois, dans les environnements dynamiques où les charges de travail évoluent et changent, l'approche basée sur les requêtes produit de meilleurs résultats.