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?

Respuestas a la pregunta(2)

Su respuesta a la pregunta