Est-ce un indice de jointure dangereux?

Question

Un collègue m'a demandé de regarder l'indexation sur certaines tables car sa requête fonctionnait très longtemps. Plus d'une heure.

Notez les différentes bases de données. Cela a été exécuté à partir de la base de donnéesB

Les tableaux 1 et 2 étaient longs de plus de 2 millions d'enregistrements. Table3 avait une douzaine d'enregistrements ou plus.

J'ai regardé le plan de requête et l'optimiseur a décidé de faire des recherches d'index nested-loop dans les tables 1 et 2 avec Table3 comme table de pilotage!

Ma première hypothèse était que les statistiques ont été sérieusement foiré sur tableaux1 & 2 mais avant les statistiques de mise à jour j'ai essayé d'ajouter un indicateur de jointure thusly:

select count(1) 
from databaseA.dbo.table1 
inner HASH join databaseA.dbo.table2 on (table1.key = table2.key) 
inner join databaseB.dbo.table3 on (table1.key = table3.key) 

résultats retournés en 15 secondes. Comme j'étais à court de temps, je lui ai transmis les résultats, mais je crains que cela puisse entraîner des problèmes sur la route.

Dois-je revoir le problème de statistiques et résoudre le problème de cette façon? Le plan de requêtes incorrectes peut-il provenir de la jointure provenant d'une base de données distincte?

Quelqu'un peut-il me proposer des idées en fonction de votre expérience?

Answer 1

Je suspecterais les statistiques d'abord. Comme vous le savez sans doute, les astuces Join devraient être évitées dans 99% des cas et utilisées uniquement lorsque vous avez la preuve qu'elles sont absolument nécessaires.

Answer 2

Vérifiez les statistiques et l'indexation sur la table en premier. Les indices d'index peuvent causer des problèmes. Si les données dans les tables changent, l'optimiseur ne pourra pas choisir un plan plus efficace puisque vous l'avez forcé à toujours utiliser un hachage.

Answer 3

Une boucle imbriquée ne serait-elle pas la plus appropriée? Prenez les 12 dossiers du tableau 3,, correspondre aux 12 enregistrements dans le tableau 1, à 12 correspondance des enregistrements dans le tableau 2.

Sinon, votre jointure de hachage ferait respecter la commande aussi bien - ce qui signifie que vous auriez hachez 1 million d'enregistrements de Table 1 et Table 2, puis joignez les 12 enregistrements du tableau 3.

Je regarderais les statistiques pour les deux plans - et je soupçonnerais que la jointure de boucle est réellement plus efficace, mais a été bloquée ou votre hachage rejoindre profitait des données mises en cache. Mais - oui - en général, les astuces de jointure sont un dernier recours.

Answer 4

Une requête à exécution lente impliquant des serveurs liés peut être liée au classement. Voir ici pour quelque arrière-plan: http://blogs.msdn.com/psssql/archive/2008/02/14/how-it-works-linked-servers-and-collation-compatibility.aspx L'indicateur de jointure de hachage force le trieur, ce qui explique le gain de performance.

Voici comment définir les options:

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'collation compatible', 
    @optvalue=N'true' 

EXEC master.dbo.sp_serveroption 
    @server=N'databaseA', 
    @optname=N'use remote collation', 
    @optvalue=N'false' 

-Edoode