Perché una query rallenta drasticamente se nella clausola WHERE una costante viene sostituita da un parametro (con lo stesso valore)?

Question

Ho una query ricorsiva che viene eseguita molto velocemente se la clausola WHERE contiene una costante ma diventa molto lenta se sostituisco la costante con un parametro con lo stesso valore.

Domanda # 1 - con la costante

;WITH Hierarchy (Id, ParentId, Data, Depth) 
AS 
(SELECT Id, ParentId, NULL AS Data, 0 AS Depth 
    FROM Test 
    UNION ALL 
    SELECT h.Id, t.ParentId, COALESCE(h.Data, t.Data), Depth + 1 AS Depth 
    FROM Hierarchy h 
     INNER JOIN Test t ON t.Id = h.ParentId 
) 
SELECT * 
FROM Hierarchy 
WHERE Id = 69 

Query # 2 - con il parametro

DECLARE @Id INT 
SELECT @Id = 69 

;WITH Hierarchy (Id, ParentId, Data, Depth) 
AS 
(SELECT Id, ParentId, NULL AS Data, 0 AS Depth 
    FROM Test 
    UNION ALL 
    SELECT h.Id, t.ParentId, COALESCE(h.Data, t.Data), Depth + 1 AS Depth 
    FROM Hierarchy h 
     INNER JOIN Test t ON t.Id = h.ParentId 
) 
SELECT * 
FROM Hierarchy 
WHERE Id = @Id 

In caso di una tabella con 50.000 righe la query con le piste costanti per 10 millisecondi e quello con il parametro funziona per 30 secondi (3000 volte più lento).

Non è un'opzione per spostare l'ultima clausola WHERE alla definizione di ancoraggio della ricorsione, poiché desidero utilizzare la query per creare una vista (senza l'ultimo WHERE). La selezione dalla vista avrebbe la clausola WHERE (WHERE Id = @Id) - Ne ho bisogno a causa di Entity Framework, ma questa è un'altra storia.

Qualcuno può suggerire un modo per forzare la query n. 2 (con il parametro) per utilizzare lo stesso piano di query della query n. 1 (con la costante)?

Ho già provato a giocare con gli indici, ma questo non ha aiutato.

Se qualcuno vorrebbe poter pubblicare la definizione della tabella e alcuni dati di esempio. Sto usando SQL 2008 R2.

Grazie per il vostro aiuto in anticipo!

esecuzione del piano - Domanda # 1 - con la costante

esecuzione del piano - Query # 2 - con il parametro

Answer 1

Come suggerito da Martin in un commento sotto la domanda, il problema è che il server SQL non esegue correttamente il push del predicato dalla clausola WHERE - vedere il collegamento nel suo commento.

Ho finito per creare una funzione con valori di tabella definita dall'utente e usarla con l'operatore CROSS APPLY per creare la vista.

Vediamo la soluzione stessa.

User Defined

CREATE VIEW [dbo].[TestView] 
AS 
SELECT t.Id, t.ParentId, f.Data, f.Depth 
FROM 
    Test AS t 
    CROSS APPLY TestFunction(Id) as f 

Query con valori di tabella funzioni

CREATE FUNCTION [dbo].[TestFunction] (@Id INT) 
RETURNS TABLE 
AS 
RETURN 
(
    WITH 
    Hierarchy (Id, ParentId, Data, Depth) 
    AS(
    SELECT Id, ParentId, NULL AS Data, 0 AS Depth FROM Test Where Id = @Id 
    UNION ALL 
    SELECT h.Id, t.ParentId, COALESCE(h.Data, t.Data), Depth + 1 AS Depth 
     FROM Hierarchy h 
      INNER JOIN Test t ON t.Id = h.ParentId 
    ) 
    SELECT * FROM Hierarchy 
) 

View con costante

SELECT * FROM TestView WHERE Id = 69 

query con il parametro

DECLARE @Id INT 
SELECT @Id = 69 
SELECT * FROM TestView WHERE Id = @Id 

La query con il parmater esegue fondamentalmente veloce come la query con la costante.

Grazie Martin e anche per gli altri!

Answer 2

Per la vostra seconda query provare a utilizzare OPTIMIZE FOR o OPTION (RECOMPILE) query hint per vedere se questo lo costringe a ricompilare lile in base al valore del parametro fornito.

Answer 3

È necessario utilizzare uno plan guide per bloccare il piano desiderato.

Answer 4

Questo potrebbe essere il suggerimento peggiore di sempre, ma hai pensato di creare uno sproc per creare la tua query come stringa ed eseguirla usando sp_executesql?

Non so nulla del comportamento di caching di SQL eseguito da sp_executesql, è stata solo la prima cosa che mi è venuta in mente.