J'ai une table SQL Server avec la structure suivante:
CREATE TABLE [dbo].[Log]( [LogID] [bigint] IDENTITY(1,1) NOT NULL, [A] [int] NOT NULL, [B] [int] NOT NULL, [C] [int] NOT NULL, [D] [int] NOT NULL, [E] [int] NOT NULL, [Flag1] [bit] NOT NULL, [Flag2] [bit] NOT NULL, [Flag3] [bit] NOT NULL, [Counter] [int] NOT NULL, [Start] [datetime] NOT NULL, [End] [datetime] NOT NULL)
5 Réponses :
Une approche est de laisser SQL Server vous dire l'utilisation optimale. Exécutez une trace pendant quelques min pendant que la table est sous une utilisation "typique", puis exécutez le conseiller de syntonisation du moteur de base de données
... et il renvoie 0 recommandations! :)))))
Brillant, c'est la voie à suivre :)
Combien d'enregistrements étaient dans la table lorsque vous avez fait ce test est la question? Parfois, une analyse de l'index ou une analyse de table est mauvaise, mais pour une petite table, ce n'est pas grave. Je suppose que le conseiller de syntonisation du moteur ne pensait pas que des index puissent améliorer les performances.
Les tables de journal sont rarement indexées, car l'indexation ralentit insertion, mise à jour et supprimer des instructions.
Je recommanderais soit:
Fondamentalement - si la vitesse / la performance est une grosse préoccupation, indexez les enregistrements sous une autre forme de tableau afin que la journalisation n'est pas affectée.
Je doute que quiconque puisse faire quelque chose, mais une supposition - vous devez enregistrer l'utilisation de la table et voir à partir de cette utilisation quelles combinaisons de colonnes sont interrogées.
- Créez un indice "maître" qui tiendrait toutes ces colonnes
C'est définitivement
pas une bonne idée - si vous avez un index sur (A, B, C, D, E) et vous limitez votre requête par des valeurs de B et D, cet index est totalement inutile. C'est seulement utile
- Si vous interrogez par Toutes les cinq colonnes fréquemment
- Par combinaisons comme (A, B), (A, B, C), (A, B, C, D) fréquemment
Dans n'importe quel autre cas, c'est un gaspillage - n'utilisez pas cela.
- Identifiez certaines des combinaisons de filtres les plus utilisées par ex. [A, D, E], [A, Démarrer, fin] etc. et créer des index Pour eux
Oui, c'est vraiment la seule façon qui promet de succès. Vous devez voir quel type de requêtes se produisent réellement, puis modifier pour ceux-ci.
Dans n'importe quel index Combinaiton, les touches internes ne peuvent être utilisées que si la clé extérieure est également référencée. Dites que vous avez un index sur Ce sont les règles très fondamentales. Ajouter à cela que les conditions de jointure peuvent ou non être considérées comme les mêmes que les clauses. Et pour obtenir des résultats plus importants, les index de non-couvrant peuvent frapper Le point de basculement . Et les index peuvent satisfaire non seulement les conditions de recherche, elles peuvent également aider à la commande par clauses. Les index réels à créer dépendent beaucoup sur les capacités de votre requête, les fonctionnalités d'E / S, la charge de mise à jour et sur la base de la taille de la taille des données (impact de la taille des fichiers et des sauvegardes). Le moteur vous donnera des allusions sur les indices pourraient être utilisés pour les requêtes (le Fonction d'index manquants ) Mais le moteur n'équilibrera à aucun cas les avantages de l'indice avec le coût d'un index supplémentaire (E / S, met à jour la performance, la taille des données). Il y a Directives de conception de l'index qui sont assez bonnes, mais bien sûr, vous avoir à aller les lire. En fin de compte, choisir des indices appropriés dépend de nombreux facteurs et des consignes qui sont impossiques pour donner une réponse à la coiffeuse de cookies. (a, b, c, d) :
où a = @ a et b = @ b et c = @ c et d = @ d utilisera pleinement l'index
où a = @ a peut utiliser l'index pour filtrer la gamme de lignes pour numériser. Idem pour où a = @ a et b = @ b , où a = @ a et c = @ c etc. Toute combinaison qui a la colonne la plus à gauche ( Un ) dans celui peut utiliser l'index.
où b = @ b ne peut pas utiliser l'index. NOR où c = @ c , où d = @ d et toute autre combinaison qui est malng a . En d'autres termes, si la colonne A n'est pas dans les restrictions de la requête, l'index est inutilisable.
Je placerais un index sur Démarrage (DateTime) et c'est tout, en supposant que peu de questions contre le journal seront créées à jour et la plupart dureront d'un point de départ.