Hasta que no se proporcionen la estructura de la tabla y los datos de muestra de resultados esperados, aquí hay algunas cosas rápidas que veo que se pueden mejorar (algunas de las cuales ya han sido mencionadas por otros anteriormente):
- WHILE Loop también es un cursor. Por lo tanto, cambiar a un bucle while no hará que las cosas sean más rápidas.
- Utilice el cursor LOCAL FAST_FORWARD a menos que necesite retroceder un registro. Esto haría que la ejecución fuera mucho más rápida.
-
Sí, estoy de acuerdo en que tener un enfoque basado en SET sería el más rápido en la mayoría de los casos, sin embargo, si debe almacenar un conjunto de resultados intermedio en algún lugar, sugeriría usar una tabla temporal en lugar de una variable de tabla. La tabla temporal es el "mal menor" entre estas 2 opciones. Aquí hay algunas razones por las que debería intentar evitar el uso de una variable de tabla:
- Dado que SQL Server no tendría estadísticas previas sobre la variable de la tabla durante la creación del Plan de ejecución, siempre considerará que la variable de la tabla solo devolverá un registro durante la construcción del plan de ejecución. Y, en consecuencia, Storage Engine asignaría solo la cantidad de memoria RAM para la ejecución de la consulta. Pero en realidad, podría haber millones de registros que la variable de tabla podría contener durante la ejecución. Si eso sucede, SQL Server se verá obligado a derramar los datos en el disco duro durante la ejecución (y verá muchos PAGEIOLATCH en sys.dm_os_wait_stats), lo que hará que las consultas sean mucho más lentas.
- Una forma de deshacerse del problema anterior sería proporcionar una OPCIÓN de sugerencia de nivel de declaración (RECOMPILAR) al final de cada consulta donde se usa un valor de tabla. Esto obligaría a SQL Server a construir el plan de ejecución de esas consultas cada vez durante el tiempo de ejecución y se puede evitar el problema de asignación de menos memoria. Sin embargo, la desventaja de esto es que SQL Server ya no podrá aprovechar un plan de ejecución ya almacenado en caché para ese procedimiento almacenado y requerirá una recompilación cada vez, lo que deterioraría el rendimiento en cierta medida. Por lo tanto, a menos que sepa que los datos en la tabla subyacente cambian con frecuencia o que el procedimiento almacenado en sí mismo no se ejecuta con frecuencia, los MVP de Microsoft no recomiendan este enfoque.
