Ajout d'index supplémentaires (raffinés) à la table SQL Server

Je suis encore en train d'apprendre les points les plus fins des index et c'est quelque chose dont je ne vois pas le besoin. J'espère que la communauté pourra me diriger dans la bonne direction.

La table a plus de 6 champs.

Field1 est un identificateur unique et est le PK. Les champs 2 et 3 sont également des identifiants uniques. Le rest est varchar / ints et hors de propos pour autant que je puisse voir.

trois index ont été placés sur la table: Clustered PK Nonclustered Non-Unique sur Field2 Nonclustered Non-Unique sur Field2 AND Field3

Il n'y a aucune colonne incluse sur l'un des index.

Ma question est, y a-t-il une raison d'avoir l'index unique sur field2? Ma compréhension est qu'il ne devrait pas y avoir de différence dans la search de l'index s'il y a deux colonnes ou un?

Tu as raison. Il y a peu de raisons que je peux penser que l'index sur Field2 seul soit utile, étant donné l'existence de l'index sur Field2 et Field3 et le fait que les colonnes incluses sont les mêmes (ie aucune):

  1. Pour s'assurer que Field2 est unique (s'il s'agit d'un index unique) – étant donné que Field2 est un identificateur unique, cela est très improbable
  2. Des raisons de performances ésotériques (techniquement, l'index sur Field2 sera plus petit donc il y aura less de fardeau d'E / S).
  3. Raisons de locking ésotérique

La loi de Sturgeon suggère que cela ne fait probablement rien d'utile, mais la loi de Murphy suggère de supprimer cela pour casser quelque chose.

Le nombre de colonnes (données) a augmenté dans la définition de l'index, cela signifie que la taille de l'index augmentera proportionnellement. Il est donc conseillé de créer une key primaire (index) sur un champ petit / entier.

par exemple, imaginez que vous searchz une table sur trois colonnes

état, comté, zip.

vous searchz parfois uniquement par état. vous cherchez parfois par l'état et le comté. vous effectuez fréquemment une search par état, comté, zip. Puis un index avec l'état, le comté, le zip. sera utilisé dans chacune de ces trois searchs.

Si vous effectuez souvent une search par zip seul, l'index ci-dessus ne sera pas utilisé (par SQL Server de toute façon) car zip est la troisième partie de cet index et l'optimiseur de requêtes ne verra pas cet index utile.

Vous pourriez alors créer un index sur Zip seul qui serait utilisé dans cette instance.

Je suppose que la réponse que vous searchz est que cela dépend de vos clauses where de vos requêtes fréquemment utilisées et de vos groupes.

Champ1 a un index parce qu'il a été nommé la key primaire et a probablement une valeur par défaut de newid (). Cela doit être unique.

La raison pour laquelle Field2 a un index est parce que c'est une key étrangère et sera probablement trouvée dans de nombreuses clauses where et instructions de jointure internes.

Vous ne savez pas pourquoi Field3 a reçu un index, mais s'il est utilisé dans n'importe quelle clause where, il est bon de l'avoir ici.

Les index sont tous sur la search rapide d'informations. Examinez toutes vos clauses where et déterminez les meilleurs indices pour vos besoins individuels.

Ma seule préoccupation serait que Field2 soit un FK et qu'une suppression soit effectuée dans la table à laquelle il se réfère, que l'optimiseur soit assez intelligent pour utiliser l'index composite avec Field2 comme première colonne à vérifier et s'assurer que rien ne se réfère à la ligne supprimé Bien sûr, l'index plus large est encore un peu less efficace, car il correspond à less de lignes par page.

La seule autre chose pourrait être ascendante / descendante, mais vous n'avez pas mentionné de différence ici.

Vous pouvez vérifier le plan d'exécution d'une telle opération et les index manquants DMV après avoir supprimé l'index redondant.

Normalement, nous commençons toujours par PK, FK tous indexés donc les opérations liées à l'intégrité de base sont correctes pour la performance; les index composites sont ensuite ajoutés pour les performances de lecture. Évidemment, à ce moment-là, certains index FK finissent par être redondants et vous vous retrouvez dans cette situation.