ABSOLUUT. Een hash-match zou een enorme verbetering zijn. Het maken van de hash op de kleinere 19.223 rijentabel en er vervolgens in zoeken met de grotere 65.991 rijentabel is een veel kleinere bewerking dan de geneste lus die 1.268.544.993 rijvergelijkingen vereist.
De enige reden waarom de server de geneste lussen zou kiezen, is dat hij het aantal betrokken rijen ernstig heeft onderschat. Beschikken uw tabellen over statistieken, en zo ja, worden deze regelmatig bijgewerkt? Statistieken stellen de server in staat om goede uitvoeringsplannen te kiezen.
Als je de statistieken correct hebt behandeld en nog steeds een probleem hebt, kun je het als volgt dwingen een HASH-join te gebruiken:
SELECT *
FROM
TableA A -- The smaller table
LEFT HASH JOIN TableB B -- the larger table
Houd er rekening mee dat op het moment dat u dit doet, ook de join-order wordt geforceerd. Dit betekent dat u al uw tafels correct moet rangschikken, zodat hun volgorde van samenvoegen logisch is. Over het algemeen zou u het uitvoeringsplan dat de server al heeft onderzoeken en de volgorde van uw tabellen in de query aanpassen om overeen te komen. Als u niet bekend bent met hoe u dit moet doen, is de basis dat elke "linkse" invoer eerst komt, en in grafische uitvoeringsplannen is de linkerinvoer de lagere een. Een complexe join waarbij veel tabellen betrokken zijn, moet mogelijk joins tussen haakjes groeperen of RIGHT JOIN gebruiken om het uitvoeringsplan optimaal te krijgen (verwissel de linker- en rechterinvoer, maar introduceer de tabel op het juiste punt in de samenvoegvolgorde).
Het is over het algemeen het beste om het gebruik van join-hints en het forceren van de join-volgorde te vermijden, dus doe eerst wat u kunt! Je zou kunnen kijken naar de indexen op de tabellen, fragmentatie, het verkleinen van kolomgroottes (zoals het gebruik van varchar in plaats van nvarchar waar Unicode niet vereist is), of het splitsen van de query in delen (eerst invoegen in een tijdelijke tabel en daarna aansluiten).