ABSOLUT. En hashmatch skulle vara en enorm förbättring. Att skapa hash på den mindre tabellen med 19 223 rader och sedan söka i den med den större tabellen med 65 991 rader är en mycket mindre operation än den kapslade slingan som kräver 1 268 544 993 radjämförelser.
Den enda anledningen till att servern skulle välja de kapslade slingorna är att den kraftigt underskattade antalet inblandade rader. Har dina tabeller statistik över dem, och i så fall uppdateras de regelbundet? Det är statistik som gör det möjligt för servern att välja bra genomförandeplaner.
Om du har åtgärdat statistik korrekt och fortfarande har ett problem kan du tvinga den att använda en HASH-koppling så här:
SELECT *
FROM
TableA A -- The smaller table
LEFT HASH JOIN TableB B -- the larger table
Observera att i samma ögonblick som du gör detta kommer det också att tvinga fram anslutningsordern. Det betyder att du måste ordna alla dina bord korrekt så att deras sammanfogningsordning är vettig. I allmänhet skulle du undersöka exekveringsplanen som servern redan har och ändra ordningen på dina tabeller i frågan för att matcha. Om du inte är bekant med hur man gör detta är grunderna att varje "vänster" ingång kommer först, och i grafiska exekveringsplaner är den vänstra ingången den nedre ett. En komplex koppling som involverar många tabeller kan behöva gruppera kopplingar inom parentes, eller använda RIGHT JOIN för att få exekveringsplanen att bli optimal (byt vänster och höger ingångar, men introducera tabellen vid rätt punkt i sammanfogningsordningen).
Det är i allmänhet bäst att undvika att använda anslutningstips och tvinga fram ordningsföljd, så gör vad du kan först! Du kan titta på indexen på tabellerna, fragmentering, minska kolumnstorlekar (som att använda varchar istället för nvarchar där Unicode inte krävs), eller dela upp frågan i delar (infoga först i en temporär tabell och gå sedan med i den).