El rendimiento del plan de ejecución del procedimiento almacenado de SQL es deficiente - análisis de parámetros
Tengo un procedimiento almacenado que acepta una entrada de fecha que luego se establece en la fecha actual si no se pasa ningún valor:
<code>CREATE PROCEDURE MyProc @MyDate DATETIME = NULL AS IF @MyDate IS NULL SET @MyDate = CURRENT_TIMESTAMP -- Do Something using @MyDate </code>
Estoy teniendo problemas por lo que si@MyDate
se pasa comoNULL
cuando el procedimiento almacenado se compila por primera vez, el rendimiento es siempre terrible para todos los valores de entrada (NULL
o de lo contrario), borrar si una fecha / la fecha actual se pasa cuando se compila el procedimiento almacenado, el rendimiento es correcto para todos los valores de entrada (NULL
o de otro modo).
Lo que también es confuso es que el mal plan de ejecución que se genera es terrible, incluso cuando el valor de @MyDate utilizado esactualmente NULL
(y no establecido enCURRENT_TIMESTAMP
por la declaración del FI)
Descubrí que deshabilitar el rastreo de parámetros (al falsificar el parámetro) soluciona mi problema:
<code>CREATE PROCEDURE MyProc @MyDate DATETIME = NULL AS DECLARE @MyDate_Copy DATETIME SET @MyDate_Copy = @MyDate IF @MyDate_Copy IS NULL SET @MyDate_Copy = CURRENT_TIMESTAMP -- Do Something using @MyDate_Copy </code>
Sé que esto tiene algo que ver con la detección de parámetros, pero todos los ejemplos que he visto de "inhalación de parámetros no funcionan" han implicado que el procedimiento almacenado se haya compilado con un parámetro no representativo, sin embargo, aquí veo que el plan de ejecución es terrible para todos los valores concebibles que el servidor SQL podría pensar que el parámetro podría tomar en el punto donde se ejecuta la instrucción:NULL
, CURRENT_TIMESTAMP
o de otro modo.
¿Alguien tiene alguna idea de por qué esto está sucediendo?