ABSOLUTAMENTE. Un hash match sería una gran mejora. Crear el hash en la tabla más pequeña de 19 223 filas y luego probarlo con la tabla más grande de 65 991 filas es una operación mucho más pequeña que el bucle anidado que requiere comparaciones de 1 268 544 993 filas.
La única razón por la que el servidor elegiría los bucles anidados es que subestimó gravemente el número de filas involucradas. ¿Sus tablas tienen estadísticas sobre ellas y, de ser así, se actualizan periódicamente? Las estadísticas son las que permiten al servidor elegir buenos planes de ejecución.
Si ha abordado correctamente las estadísticas y todavía tiene un problema, puede forzarlo a usar una unión HASH así:
SELECT *
FROM
TableA A -- The smaller table
LEFT HASH JOIN TableB B -- the larger table
Tenga en cuenta que en el momento en que haga esto, también forzará el orden de unión. Esto significa que debe organizar todas sus tablas correctamente para que su orden de unión tenga sentido. En general, examinaría el plan de ejecución que ya tiene el servidor y alteraría el orden de sus tablas en la consulta para que coincida. Si no está familiarizado con cómo hacer esto, lo básico es que cada entrada "izquierda" viene primero, y en los planes de ejecución gráfica, la entrada izquierda es la inferior una. Una unión compleja que involucre muchas tablas puede tener que agrupar las uniones entre paréntesis, o usar RIGHT JOIN para que el plan de ejecución sea óptimo (intercambie las entradas izquierda y derecha, pero introduzca la tabla en el punto correcto en el orden de unión).
En general, es mejor evitar el uso de sugerencias para unirse y forzar el orden de unión, ¡así que haga lo que pueda primero! Podría buscar en los índices de las tablas, la fragmentación, la reducción del tamaño de las columnas (como usar varchar en lugar de nvarchar donde no se requiere Unicode), o dividir la consulta en partes (insertar primero en una tabla temporal y luego unirla).
