Surpresas e suposições de desempenho:DATEDIFF

SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0),
       CONVERT(DATE, DATEADD(DAY, 1 - DAY(GETDATE()), GETDATE()));

SELECT SYSDATETIME();
GO
DECLARE @d DATE = DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0);
GO 1000000
GO
SELECT SYSDATETIME();
GO
DECLARE @d DATE = DATEADD(DAY, 1 - DAY(GETDATE()), GETDATE());
GO 1000000
SELECT SYSDATETIME();

SELECT DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0), -- today: 2013-09-01
       DATEADD(MONTH, DATEDIFF(MONTH, GETDATE(), 0), 0); -- today: 1786-05-01
--------------------------------------^^^^^^^^^^^^ notice how these are swapped

Uma reprodução

CREATE TABLE dbo.DateTest
(
  CreateDate DATE
);
 
CREATE CLUSTERED INDEX x ON dbo.DateTest(CreateDate);
 
INSERT dbo.DateTest(CreateDate) 
SELECT TOP (15000) DATEADD(MONTH, DATEDIFF(MONTH, GETDATE(), 0), 0)
FROM sys.all_objects AS s1
CROSS JOIN sys.all_objects AS s2
UNION ALL
SELECT TOP (50) DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0)
FROM sys.all_objects;

SELECT /* Query 1 */ COUNT(*) FROM dbo.DateTest
  WHERE CreateDate = DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0);
 
SELECT /* Query 2 */ COUNT(*) FROM dbo.DateTest
  WHERE CreateDate = DATEADD(MONTH, DATEDIFF(MONTH, GETDATE(), 0), 0);

SELECT /* Query 3 */ COUNT(*) FROM dbo.DateTest
  WHERE CreateDate = CONVERT(DATE, DATEADD(DAY, 1 - DAY(GETDATE()), GETDATE()));

Então, por que isso acontece?

Há uma correção – ou há?

1. O artigo da KB afirma que o problema foi corrigido em vários service packs ou atualizações cumulativas para SQL Server 2005, 2008 e 2008 R2. No entanto, o sintoma ainda está presente em ramificações que não são mencionadas explicitamente, mesmo que tenham visto muitas CUs adicionais desde que o artigo foi publicado. Ainda posso reproduzir esse problema no SQL Server 2008 SP3 CU #8 (10.0.5828) e no SQL Server 2012 SP1 CU #5 (11.0.3373).
   
2. Ele esquece de mencionar que, para se beneficiar da correção, você precisa ativar o sinalizador de rastreamento 4199 (e "se beneficiar" de todas as outras maneiras pelas quais o sinalizador de rastreamento específico pode afetar o otimizador). O fato de esse sinalizador de rastreamento ser necessário para a correção é mencionado em um item relacionado do Connect, #630583, mas essas informações não chegaram ao artigo da base de conhecimento. Nem o artigo da base de conhecimento nem o item Connect fornecem informações sobre a causa (que os argumentos para DATEDIFF foram trocados durante a avaliação). No lado positivo, executando as consultas acima com o sinalizador de rastreamento ativado (usando OPTION (QUERYTRACEON 4199) ) gera planos que não apresentam o problema de estimativa incorreta.
   
3. Sugere que você use SQL dinâmico para solucionar o problema. Nos meus testes, usando uma expressão diferente (como a acima que não usa DATEDIFF ) superou o problema nas compilações modernas do SQL Server 2008 e do SQL Server 2012. Recomendar SQL dinâmico aqui é desnecessariamente complexo e provavelmente um exagero, já que uma expressão diferente poderia resolver o problema. Mas se você usasse SQL dinâmico, eu faria dessa maneira, em vez da maneira que eles recomendam no artigo da KB, o mais importante para minimizar os riscos de injeção de SQL:
   
   

   DECLARE 
     @date DATE = DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0),
     @sql NVARCHAR(MAX) = N'SELECT COUNT(*) FROM dbo.DateTest 
       WHERE CreateDate = @date;';
    
   EXEC sp_executesql @sql, N'@date DATE', @date;

   
   (E você pode adicionar OPTION (RECOMPILE) lá, dependendo de como você deseja que o SQL Server lide com a detecção de parâmetros.)
   
   Isso leva ao mesmo plano da consulta anterior que não usa DATEDIFF , com estimativas adequadas e busca de 99,1% do custo no índice clusterizado.
   
   Outra abordagem que pode tentá-lo (e por você, quero dizer eu, quando comecei a investigar) é usar uma variável para calcular o valor de antemão:
   

   DECLARE @d DATE = DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0);
    
   SELECT COUNT(*) FROM dbo.DateTest WHERE CreateDate = @d;

   
   O problema com essa abordagem é que, com uma variável, você terminará com um plano estável, mas a cardinalidade será baseada em um palpite (e o tipo de palpite dependerá da presença ou ausência de estatísticas) . Nesse caso, aqui estão os valores estimados versus reais:
   
   
   Aba de operações principais para consulta que usa uma variável
   
   Isso claramente não está certo; parece que o SQL Server adivinhou que a variável corresponderia a 50% das linhas na tabela.

SQL Server 2014

SELECT /* 0, GETDATE() (2013) */ COUNT(*) FROM dbo.DateTest
  WHERE CreateDate = DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0);
 
SELECT /* GETDATE(), 0 (1786) */ COUNT(*) FROM dbo.DateTest
  WHERE CreateDate = DATEADD(MONTH, DATEDIFF(MONTH, GETDATE(), 0), 0);
 
SELECT /* Non-DATEDIFF */ COUNT(*) FROM dbo.DateTest
  WHERE CreateDate = CONVERT(DATE, DATEADD(DAY, 1 - DAY(GETDATE()), GETDATE()));
 
DECLARE @d DATE = DATEADD(DAY, 1 - DAY(GETDATE()), GETDATE());
 
SELECT /* Variable */ COUNT(*) FROM dbo.DateTest WHERE CreateDate = @d;
 
DECLARE 
  @date DATE = DATEADD(MONTH, DATEDIFF(MONTH, 0, GETDATE()), 0),
  @sql NVARCHAR(MAX) = N'SELECT /* Dynamic SQL */ COUNT(*) FROM dbo.DateTest 
    WHERE CreateDate = @date;';
 
EXEC sp_executesql @sql, N'@date DATE', @date;

Conclusão