ABSOLUT. Et hash-match ville være en kæmpe forbedring. At oprette hashen på den mindre tabel med 19.223 rækker og derefter søge i den med den større tabel med 65.991 rækker er en meget mindre operation end den indlejrede løkke, der kræver 1.268.544.993 rækkesammenligninger.
Den eneste grund til, at serveren ville vælge de indlejrede løkker, er, at den undervurderede antallet af involverede rækker stærkt. Har dine tabeller statistik over dem, og i så fald bliver de opdateret løbende? Statistik er det, der gør serveren i stand til at vælge gode eksekveringsplaner.
Hvis du har behandlet statistik korrekt og stadig har et problem, kan du tvinge den til at bruge en HASH-join som sådan:
SELECT *
FROM
TableA A -- The smaller table
LEFT HASH JOIN TableB B -- the larger table
Bemærk venligst, at i det øjeblik du gør dette, vil det også tvinge tilslutningsordren. Det betyder, at du skal arrangere alle dine borde korrekt, så deres rækkefølge giver mening. Generelt vil du undersøge den eksekveringsplan, som serveren allerede har, og ændre rækkefølgen af dine tabeller i forespørgslen, så den matcher. Hvis du ikke er bekendt med, hvordan du gør dette, er det grundlæggende, at hvert "venstre" input kommer først, og i grafiske udførelsesplaner er venstre input det nedre en. En kompleks joinforbindelse, der involverer mange tabeller, skal muligvis gruppere joinforbindelser inden for parenteser eller bruge RIGHT JOIN for at få udførelsesplanen til at være optimal (byt venstre og højre input, men indfør tabellen på det rigtige sted i sammenføjningsrækkefølgen).
Det er generelt bedst at undgå at bruge join-tip og tvinge join-rækkefølge, så gør hvad du ellers kan først! Du kan se på indekserne på tabellerne, fragmentering, reduktion af kolonnestørrelser (såsom brug af varchar i stedet for nvarchar hvor Unicode ikke er påkrævet), eller opdeling af forespørgslen i dele (indsæt først til en midlertidig tabel, og tilslut den derefter).