Prestare attenzione alle stime

Non ho intenzione di suggerire che questo sia un elenco esaustivo, e non ho intenzione di ribadire il consiglio di Paul su suggerimenti o flag di traccia, quindi mi concentrerò solo sul mostrare come i primi quattro approcci possono mitigare il problema con stime errate .

1. Parametri della data

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. Procedura di confezionamento

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. OPZIONE (RICIMPILA)

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 dinamico

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

Le prove

Con i quattro insiemi di procedure in atto, è stato facile costruire test che mi avrebbero mostrato i piani e le stime derivate da SQL Server. Poiché alcuni mesi sono più impegnativi di altri, ho scelto tre mesi diversi e li ho eseguiti tutti più volte.

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 */

Il risultato? Ogni singolo piano produce la stessa ricerca dell'indice, ma le stime sono corrette solo in tutti e tre gli intervalli di date nel OPTION (RECOMPILE) versione. Gli altri continuano a utilizzare le stime derivate dal primo set di parametri (luglio 2012), e così, mentre ottengono stime migliori per il primo esecuzione, tale stima non sarà necessariamente migliore per il successivo esecuzioni che utilizzano parametri diversi (un classico caso di sniffing dei parametri da manuale):

Si noti che quanto sopra non è un output *esatto* da SQL Sentry Plan Explorer:ad esempio, ho rimosso le righe dell'albero delle istruzioni che mostravano le chiamate della stored procedure esterna e le dichiarazioni dei parametri.

Starà a te determinare se la tattica di compilare ogni volta è la migliore per te o se devi "aggiustare" qualcosa in primo luogo. Qui, abbiamo finito con gli stessi piani e nessuna differenza evidente nelle metriche delle prestazioni di runtime. Ma su tabelle più grandi, con una distribuzione dei dati più distorta e varianze maggiori nei valori dei predicati (ad esempio, si consideri un rapporto che può coprire una settimana, un anno e qualsiasi altra via di mezzo), potrebbe valere la pena indagare. E nota che puoi combinare i metodi qui, ad esempio, puoi passare ai parametri della data corretti *e* aggiungere OPTION (RECOMPILE) , se vuoi.

Conclusione

In questo caso specifico, che è una semplificazione intenzionale, lo sforzo per ottenere le stime corrette non è stato davvero ripagato:non abbiamo ottenuto un piano diverso e le prestazioni di runtime erano equivalenti. Ci sono certamente altri casi, tuttavia, in cui questo farà la differenza, ed è importante riconoscere la disparità di stima e determinare se potrebbe diventare un problema man mano che i tuoi dati crescono e/o la tua distribuzione si inclina. Sfortunatamente, non esiste una risposta in bianco o nero, poiché molte variabili influenzeranno la giustificazione del sovraccarico di compilazione, come in molti scenari, IT DEPENDS™ …