Lors du développement de grands systèmes (des centaines de tables) Vous créez les index (et moindre mesure les autres contraintes dans le DB) lorsque vous créez des entités (tables), ou attendre que le système être en cours d'exécution (peut-être une version bêta privée) pour décider où placer les index?db application index - meilleures pratiques
Je conçois des index basés sur les scénarios de requête éventuels. Quelles seront les requêtes les plus courantes exécutées contre la table? Cela devrait informer la conception de l'index - à la fois pour optimiser les performances des requêtes et pour minimiser les frais généraux d'insertion/mise à jour/suppression.
créer simplement un index ordonné en clusters sur la clé primaire, par exemple, peut donner un sens dans un monde théorique à l'avant, mais ne peut pas refléter la charge des requêtes dans le monde réel.
Par exemple: si vous avez une table d'éléments de commande, où les éléments de commande 0-n sont associés à un ordre de parent? Créez-vous simplement une colonne d'ID d'article de commande, indiquez-la comme clé primaire et gravez votre index clusterisé même si, dans le monde réel, 90% de votre activité de requête par rapport à cette table sera "get order items for order xyz" un index clusterisé sur l'ID de commande parent peut-il avoir plus de sens que l'index clusterisé de clé primaire "par défaut" sur l'ID d'article de commande?
Vous pouvez faire beaucoup de cela à l'avance en sachant quels scénarios votre application permettra. Ensuite, vous pouvez également faire des traces dans le monde réel et les analyser pour trouver les index manquants; SQL Server, par exemple, est livré avec des outils pour ce faire, il existe également des outils tiers. Une technique que j'utilise parfois est aussi de faire une grosse trace, télécharger l'information de trace dans une table, et l'interroger pour des instructions SQL distinctes (sur la base de n'importe quel critère ... par exemple donner toutes les UPDATEs sur la table xyz ...) vous pouvez faire un plan de requête pour ces instructions et voir à quel point votre indexation est bonne, par exemple, en recherchant et en adressant les scans de table ou d'index de manière appropriée - et en vérifiant en réexaminant le plan d'exécution de la requête. Quelques mises en garde ... ne pas appliquer les index de manière bon gré mal gré sur les traces. Un index sur une table affecte les performances globales de toutes les requêtes sur la table. Ne supposez pas qu'une analyse de table ou d'index (plutôt qu'une recherche) est nécessairement mauvaise; cela n'a pas d'importance dans une table à dix rangs. L'optimisation de l'index est une combinaison de science et d'art, il est donc essentiel de rester simple. Effectuer des tests fréquemment après de petits changements incrémentiels est un bon moyen de conserver son équilibre et de pouvoir revenir en arrière fréquemment et surtout lorsque vous avez plusieurs changements. scriptez-les afin que votre DBA dispose d'un protocole exact de ce qui sera fait, et puisse facilement déterminer où/quoi revenir si nécessaire.
Si vous connaissez les champs que vous allez utiliser la plupart du temps (clauses where et order by`), vous pouvez aussi bien les créer lors de la création des entités.
Vous pouvez toujours revenir plus tard, et tout DBA digne de ce nom le ferait.
Un endroit que vous aurez presque toujours envie d'indexer est celui des champs clés. Les bases de données créent généralement automatiquement un index unique lorsqu'un PK est créé mais pas un index lorsqu'un FK est créé. Puisque vous vous joignez à ces champs, il est généralement essentiel de les indexer dès le départ. – HLGEM
Encore une chose. Vérifiez dans les vues de gestion distribuées (DMV) dans les versions récentes de SQL Server; vous pouvez surveiller les statistiques accumulées de SQL sur les requêtes les plus exécutées (procs, ad-hoc, etc.) ainsi que l'utilisation de ressources globales de chaque requête (et vous pouvez calculer les moyennes en utilisant le nombre d'exécutions). C'est un autre moyen très utile de concentrer votre travail d'optimisation là où ça compte vraiment. – pelazem