web-dev-qa-db-fra.com

Application d'index aux colonnes utilisées dans une condition de jointure

Dans la requête ci-dessous, dans quelle mesure est-il avantageux d'utiliser l'index sur les colonnes utilisées dans les conditions de jointure?

select * from table_a
inner join table_b on
           table_a.col1 = table_b.col1 and 
           table_a.col2 = table_b.col2

Dans la jointure ci-dessus, est-il avantageux d'indexer la table table_a(col1,col2) ou la table table_b(col1,col2) et l'ordre des colonnes dans l'index a-t-il un impact sur les performances?

Si supposons qu'il existe un index sur table_b(col1,col2). Cela signifie-t-il que nous devons modifier la requête comme suit?

select * from table_a
    inner join table_b on
               table_b.col1 = table_a.col1 and 
               table_b.col2 = table_a.col2
sql-serverindex-tuning
5
Madhusudan

Les index B-tree offrent trois avantages principaux:

  1. Rechercher une valeur spécifique ou une plage de valeurs
  2. Renvoyer les lignes dans l'ordre des index
  3. Taille de ligne plus petite que la table de base (index cluster ou segment de mémoire)

Sans index utiles, la stratégie de jointure principale de l'optimiseur est jointure de hachage , où les clés de jointure de la petite table sont utilisées pour construire une table de hachage, puis les clés de jointure de la plus grande table sont utilisés pour sonder cette table de hachage pour les correspondances. La jointure par hachage nécessite de la mémoire pour contenir la table de hachage complète.

Avec des index utiles, l'optimiseur peut également prendre en compte les boucles imbriquées indexées ou fusionner la jointure stratégies:

Jointure de boucles imbriquées indexées

Cette stratégie de jointure physique tire principalement parti de l'avantage n ° 1 ci-dessus. Il lit à partir de la petite table puis recherche un index sur la plus grande table sur les clés de jointure. Pour l'équi-jointure, l'ordre des clés d'index n'est pas significatif. Recherche sur (col1, col2) est possible que les clés d'index soient (col1, col2) ou (col2, col1).

Pour votre exemple, un index sur (col1, col2) ou (col2, col1) pour l'une ou l'autre table activerait une stratégie de jointure de boucles imbriquées indexées. Idéalement, l'indice serait sur la plus grande table.

Fusionner la jointure (sans tris explicites)

Cette jointure physique utilise principalement l'avantage n ° 2 ci-dessus (ordre d'index). Les index doivent inclure toutes les colonnes de jointure, dans le même ordre de clé sur les deux tables. Une jointure de fusion sur (col1, col2) peut utiliser des index sur (col1, col2) ou (col2, col1), mais l'ordre des clés doit être le même pour les deux tables.

La jointure par fusion est plus efficace lorsqu'au moins une des entrées est garantie unique sur les clés de jointure.

Pour votre exemple, les index sur (col1, col2) ou (col2, col1) sur les deux tables serait requis. Les index devraient avoir le même ordre de clé sur les deux, et idéalement, l'index serait unique sur ces colonnes pour au moins une table.

db<>fiddle démo

L'ordre textuel des prédicats de la clause ON n'est pas important. Les éléments suivants sont exactement équivalents. Ce que vous utilisez est purement une question de style:

-- I prefer this style
SELECT * 
FROM dbo.table_a AS TA
JOIN dbo.table_b AS TB
    ON TB.col1 = TA.col1
    AND TB.col2 = TA.col2;

SELECT * 
FROM dbo.table_a AS TA
JOIN dbo.table_b AS TB
    ON TA.col1 = TB.col1
    AND TA.col2 = TB.col2;

Plus généralement, l'impact des index sur le choix de jointure physique n'est qu'une partie de l'équation. Les index peuvent être utiles pour d'autres prédicats (sans jointure) dans la requête, ainsi que pour d'autres opérations telles que l'agrégation, le fenêtrage et l'ordre de présentation final.

L'équilibrage de l'utilité des index pour l'ensemble de la requête et de toutes les requêtes de la charge de travail par rapport au coût de maintenance de ces index est une partie importante de l'art de l'administration et du réglage de la base de données.

9
Paul White 9

Pour en tirer le meilleur parti, vous devez créer des index sur les deux tables.

Maintenant, en fonction de la requête, vous devrez décider quels index créer en premier lieu.

Un blog où il gratte juste la surface de l'indexation peut être trouvé ici

Vous devez également être en mesure de lire les plans d'exécution, afin de comprendre si vos index fonctionnent correctement et si vous utilisez même ces index.

Un blog sur les plans d'exécution peut être trouvé ici

Pour répondre à votre question: peu importe la table que vous initialisez en premier, car l'optimiseur de requêtes crée son propre plan et l'ordre dans lequel les tables sont jointes, sauf indication contraire (avec option (forcer l'ordre)), mais cela ne vous donnera aucune amélioration des performances si tu fais.

3
S4V1N