Acelerar ejecución procedimiento almacenado

[DjNelson]

Hola, tengo un procedimiento almacenado con varios miles de líneas de código que se va ha ejecutar un montón de veces y necesito optimizarlo para que se ejecute más rápidamente, para empezar:

¿Es más rápido declarar todas las variables en una sola línea o declararlas por separado?

Declare @nombre varchar(20)
Declare @fecha datetime
Declare @xxxx varchar(10)

o esto:

Declare @nombre varchar(20), @fecha datetime, @xxxx varchar(10)...

Saludos.

[iislas]

En la ayuda en linea, no se menciona nada al respecto, o si acaso, hubiera alguna diferencia en hacer la declaración en un solo DECLARE o hacerlo de forma individual por cada variable

[Beakdan]

Hola,
creo que estás desperdiciando tu tiempo al enfocarte en esa parte. Evidentemente, la declaración y asignación de variables tiene un costo de cpu, y mientras menos variables declaradas en tu procedimiento tengas, será mejor, pero debes tener cientos de variables antes de que la declaración / asignación de las mismas tenga que preocuparte.
Trabajo como consultor de SQL Server, y muchas veces he tenido que solucionar problemas de performance. Lo que te puedo recomendar es lo siguiente:
-Obtén el plan de ejecución de las sentencias en el procedimiento (usa el profiler) y enfócate en aquellas que tengan un mayor costo relativo.
-Revisa si tienes cursores o ciclos while y busca reemplazarlos con código "set based".
-Si tienes tablas temporales en el procedimiento, analiza si puedes reemplazarlas con "derived tables" o "common table expressions". Algunos procedimientos tienden a recompilarse con frecuencia debido al uso excesivo de tablas temporales.
-Por supuesto, analiza si tienes índices adecuados en las tablas usadas por el procedimiento, y asegúrate de que las expresiones que usas en los predicados sean "sargables".
-Si es posible, divide el procedimiento en múltiples procedimientos más pequeños.

Hay muchas otras cosas que se pueden hacer para acelerar el tiempo de respuesta, pero espero que con esto te puedes trazar un plan de acción.

Saludos.

[DjNelson]

Beakdan, apenas he entendido la mitad de lo que me has sugerido...

coidgo 'set based'?
'derived tables'?
'sargables'?

Dónde puedo encontrar un manual dónde expliquen como usar las herramientas de sql server para optimizar las consultas y como establecer los índices correctos?

Saludos.

[Beakdan]

Decoré con comillas esos términos, ya que forman parte de la jerga usada en bases de datos. Y no los he traducido al español, porque si en tu buscador indicas "tabla derivada" aparece de todo excepto el concepto de BD que pretendemos encontrar.
Set Based Code: Es como se le denomina al código SQL que hace un uso apropiado de la lógica basada en conjuntos. Cuando tienes cursores, o recorres fila por fila con loops, estás haciendo trabajar al motor de manera ineficiente. No solo eso, ciertos tipos de subconsultas correlacionadas pueden producir lo que se conoce como "triangular join", que tampoco es "set based code".
Derived Table: Es el resultado de una consulta al cual le pones un nombre y lo usas como si de una tabla física o vista se tratase. Un refinamiento mayor a este concepto son las "Common Table Expression".
Sargable: El término es una contracción de Search ARGument ABLE, que es básicamente la capacidad de que los argumentos del predicado de una consulta usen un índice apropiado en caso de que exista o llegue a existir. Cuando encuentras una recomendación como "no usar NOT LIKE", "evita usar funciones en las columnas usadas en el where", etc. estás viendo casos específicos de como evitar un predicado no sargable.

La documentación apropiada está en el MSDN por ejemplo:
http://msdn.microsoft.com/en-us/library/ff647793.aspx

O puedes conseguirte un buen libro. Hay muchísimos enfocados específicamente en optimizar código SQL, por ejemplo:
http://www.microsoft.com/learning/en...5&locale=en-us

Saludos.

[Cvilla90]

Hola, las dos formas de declarar tus variables estan correctas, en el sql el procedimiento almacenado no es lento, los resultados q arroje el sql depende tambien de la cantidad de registros q tengan tus tablas o como tambien del amarre q le hayas hecho para mostrarlo...