Prestar atención a las estimaciones

No voy a sugerir que esta es una lista exhaustiva, y no voy a reiterar el consejo de Paul sobre sugerencias o señales de seguimiento, así que solo me concentraré en mostrar cómo los primeros cuatro enfoques pueden mitigar el problema con estimaciones incorrectas. .

1. Parámetros de fecha

CREATE PROCEDURE dbo.MonthlyReport_TwoDates
  @Start date,
  @End   date
AS
BEGIN
  SET NOCOUNT ON;
 
  SELECT /* Two Dates */ DateColumn
    FROM dbo.DateEntries
    WHERE DateColumn >= @Start
      AND DateColumn <  @End;
END
GO

2. Procedimiento de envoltura

CREATE PROCEDURE dbo.MonthlyReport_WrapperTarget
  @Start date,
  @End   date
AS
BEGIN
  SET NOCOUNT ON;
 
  SELECT /* Wrapper */ DateColumn
    FROM dbo.DateEntries
    WHERE DateColumn >= @Start
      AND DateColumn <  @End;
END
GO
 
CREATE PROCEDURE dbo.MonthlyReport_WrapperSource
  @Year  int,
  @Month int
AS
BEGIN
  SET NOCOUNT ON;
  DECLARE @Start date = DATEFROMPARTS(@Year, @Month, 1);
  DECLARE @End   date = DATEADD(MONTH, 1, @Start);
 
  EXEC dbo.MonthlyReport_WrapperTarget @Start = @Start, @End = @End;
END
GO

3. OPCIÓN (RECOMPILAR)

CREATE PROCEDURE dbo.MonthlyReport_Recompile
  @Year  int,
  @Month int
AS
BEGIN
  SET NOCOUNT ON;
  DECLARE @Start date = DATEFROMPARTS(@Year, @Month, 1);
  DECLARE @End   date = DATEADD(MONTH, 1, @Start);
 
  SELECT /* Recompile */ DateColumn
    FROM dbo.DateEntries
      WHERE DateColumn >= @Start
      AND DateColumn < @End OPTION (RECOMPILE);
END
GO

4. SQL dinámico

CREATE PROCEDURE dbo.MonthlyReport_DynamicSQL
  @Year  int,
  @Month int
AS
BEGIN
  SET NOCOUNT ON;
  DECLARE @Start date = DATEFROMPARTS(@Year, @Month, 1);
  DECLARE @End   date = DATEADD(MONTH, 1, @Start);
 
  DECLARE @sql nvarchar(max) = N'SELECT /* Dynamic SQL */ DateColumn
    FROM dbo.DateEntries
    WHERE DateColumn >= @Start
    AND DateColumn < @End;';
 
  EXEC sys.sp_executesql @sql, N'@Start date, @End date', @Start, @End;
END
GO

Las Pruebas

Con los cuatro conjuntos de procedimientos implementados, fue fácil construir pruebas que me mostraran los planes y las estimaciones derivadas de SQL Server. Dado que algunos meses están más ocupados que otros, elegí tres meses diferentes y los ejecuté varias veces.

DECLARE @Year  int = 2012, @Month int = 7; -- 385 rows
DECLARE @Start date = DATEFROMPARTS(@Year, @Month, 1);
DECLARE @End   date = DATEADD(MONTH, 1, @Start);
 
EXEC dbo.MonthlyReport_Original      @Year  = @Year, @Month = @Month;
EXEC dbo.MonthlyReport_TwoDates      @Start = @Start,  @End = @End;
EXEC dbo.MonthlyReport_WrapperSource @Year  = @Year, @Month = @Month;
EXEC dbo.MonthlyReport_Recompile     @Year  = @Year, @Month = @Month;
EXEC dbo.MonthlyReport_DynamicSQL    @Year  = @Year, @Month = @Month;
 
/* repeat for @Year = 2011, @Month = 9  --    157 rows */
 
/* repeat for @Year = 2014, @Month = 4  --  2,115 rows */

¿El resultado? Todos los planes generan la misma búsqueda de índice, pero las estimaciones solo son correctas en los tres intervalos de fechas. en la OPTION (RECOMPILE) versión. El resto continúa usando las estimaciones derivadas del primer conjunto de parámetros (julio de 2012), y así mientras obtienen mejores estimaciones para el primero ejecución, esa estimación no será necesariamente mejor para subsecuente ejecuciones usando diferentes parámetros (un caso clásico de libro de texto de análisis de parámetros):

Tenga en cuenta que lo anterior no es un resultado *exacto* de SQL Sentry Plan Explorer; por ejemplo, eliminé las filas del árbol de declaraciones que mostraban las llamadas a procedimientos almacenados externos y las declaraciones de parámetros.

Dependerá de usted determinar si la táctica de compilar cada vez es mejor para usted, o si necesita "arreglar" algo en primer lugar. Aquí, terminamos con los mismos planes y sin diferencias notables en las métricas de rendimiento del tiempo de ejecución. Pero en tablas más grandes, con una distribución de datos más sesgada y mayores variaciones en los valores predicados (por ejemplo, considere un informe que puede cubrir una semana, un año y cualquier punto intermedio), puede valer la pena investigar un poco. Y tenga en cuenta que puede combinar métodos aquí; por ejemplo, puede cambiar a los parámetros de fecha adecuados *y* agregar OPTION (RECOMPILE) , si quisieras.

Conclusión

En este caso específico, que es una simplificación intencional, el esfuerzo de obtener las estimaciones correctas realmente no valió la pena:no obtuvimos un plan diferente y el rendimiento del tiempo de ejecución fue equivalente. Sin embargo, ciertamente hay otros casos en los que esto marcará la diferencia, y es importante reconocer la disparidad de estimaciones y determinar si podría convertirse en un problema a medida que sus datos crecen y/o su distribución se desvía. Desafortunadamente, no hay una respuesta absoluta, ya que muchas variables afectarán si se justifica la sobrecarga de compilación, como ocurre con muchos escenarios, IT DEPENDS™ …