Variable vs Stringliteral Geschwindigkeit Disparität

Question

Ich habe eine einfache Abfrage, die sehr schnell läuft (ca. 1 Sekunde), wenn ich einen Stringliteral in meiner WHERE Klausel, wie zum Beispiel:

select * 
from table 
where theDate >= '6/5/2016' 

jedoch diese Abfrage (das nicht wesentlich ist) läuft über 2 Minuten in:

declare @thisDate as date 
set @thisDate = '6/5/2016' 

select * 
from table 
where theDate >= @thisDate 

ich mit OPTION(RECOMPILE) versucht, so here vorgeschlagen, aber es tut nichts, um die Leistung zu verbessern. Die Spalte theDate ist eine Datetime, diese Datenbank wurde vor kurzem aus SQL Server 2005 migriert.

Es gibt keinen Index auf meiner theDate Spalte, und die Tabelle hat knapp über 1 Milliarde Zeilen. Es ist eine freigegebene Ressource und ich möchte nicht mit der Indizierung beginnen, ohne sicher zu sein, dass es hilft.

finde ich, dass unter Verwendung von Logik anstelle einer Variablen als String die gleiche Leistung bietet wörtlichen:

select * 
from table 
where theDate >= dateadd(dd, -23, getdate()) 

Aber, wenn ich das Datum ganze Zahl mit einem variablen integer ersetzen die Leistung wieder behindert wird.

Wie kann ich eine Variable hinzufügen und die Leistung beibehalten?

EDIT

tatsächliche Abfrage nach Anforderung enthalten:

DECLARE @days INT 

Set @days = 7 

select c.DEBT_KEY 
     , c.new_value 
     , c.CHANGE_DATE 
from changes c with (nolock) 
where c.C_CODE = 3 
and c.old_value = 4 
and c.CHANGE_DATE >= dateadd(dd, -@days, getdate()) 

Nein verbindet.

Abfragepläne

Mit Variable (xml explain plan):

Mit Stringliteral (xml explain plan):

So kann ich der Unterschied zu sehen ist tha t Die Variable ruft einen Clustered-Index-Scan (gruppiert) auf, während das String-Literal ein Key-Lookup (Clustered) aufruft ... Ich werde auf Google verweisen müssen, weil ich nicht wirklich etwas über die Performance-Pro/Contra-Werte weiß.

EDIT EDIT

Das funktionierte (xml explain plan):

DECLARE @days INT 

Set @days = 7 

select c.DEBT_KEY 
     , c.new_value 
     , c.CHANGE_DATE 
from changes c with (nolock) 
where c.CHANGE_CODE = 3 
and c.old_value = 4 
and c.CHANGE_DATE >= dateadd(dd, -@days, getdate()) 
OPTION(OPTIMIZE FOR (@days = 7)) 

... Ich weiß nicht, warum. Außerdem mag ich die Lösung nicht, da sie meinen Zweck der Verwendung einer Variablen negiert, die darin besteht, alle Variablen an die Spitze des Procs zu setzen, um die Notwendigkeit zu reduzieren, im Code während der unvermeidlichen Wartung herumzustochern.

Answer 1

Die schnelle Version führt eine Clusterschlüssel-Suche durch (kann direkt zu dem Teil der Tabelle gehen, in dem dieser Wert gefunden wird).

Die langsame Version führt einen nicht gruppierten Suchvorgang durch und führt diesen dann mit einem Clustered-Index-Scan zusammen (es muss die gesamte Tabelle durchsucht werden).

Ich sehe die @thisDate Variable ist definiert als Date Typ. Ist möglich, dass die Spalte als DateTime definiert ist? Wenn dies der Fall wäre, würde jeder Wert in @thisDate nicht exakt mit Ihrem Clustered-Index übereinstimmen, was bedeutet, dass die Datenbank die gesamte Tabelle überprüfen muss, wie wir hier sehen. Das Literal hingegen wird als DateTime-Wert interpretiert, der entspricht entspricht Ihrem Tabellenspalte Typ und wird mit dem Index arbeiten.

Wenn dies richtig ist, können Sie die Dinge mit einem sehr einfachen Wechsel fix:

declare @thisDate as datetime 
set @thisDate = '6/5/2016' 

Nur noch 4 Unterschied Zeichen.

Sie können dies auch in Verbindung mit OPTION(RECOMPILE) versuchen, und Sie können auch einen Blick auf OPTIMIZE FOR UNKNOWN werfen.