Dit zou beter kunnen werken:
Where FK.DT = cast(getdate() + 1 - datepart(day, getdate()) as date)
Tenzij u werkt met traceringsvlag 4199, is er een fout die de kardinaliteitsschattingen beïnvloedt. Op het moment van schrijven
SELECT DATEADD(m, DATEDIFF(m, getdate(), 0), 0),
DATEADD(m, DATEDIFF(m, 0, getdate()), 0)
Retourneren
+-------------------------+-------------------------+
| 1786-06-01 00:00:00.000 | 2013-08-01 00:00:00.000 |
+-------------------------+-------------------------+
De fout is dat het predikaat in de vraag de eerste datum gebruikt in plaats van de tweede bij het afleiden van de kardinaliteitsschattingen. Dus voor de volgende opstelling.
CREATE TABLE FK
(
ID INT IDENTITY PRIMARY KEY,
DT DATE,
Filler CHAR(1000) NULL,
UNIQUE (DT,ID)
)
INSERT INTO FK (DT)
SELECT TOP (1000000) DATEADD(m, DATEDIFF(m, getdate(), 0), 0)
FROM master..spt_values o1, master..spt_values o2
UNION ALL
SELECT DATEADD(m, DATEDIFF(m, 0, getdate()), 0)
Vraag 1
SELECT COUNT(Filler)
FROM FK
WHERE FK.DT = CAST(DATEADD(m, DATEDIFF(m, 0, getdate()), 0) AS DATE)
Schattingen dat het aantal overeenkomende rijen 100.000 zal zijn. Dit is het nummer dat overeenkomt met de datum '1786-06-01'
.
Maar beide van de volgende vragen
SELECT COUNT(Filler)
FROM FK
WHERE FK.DT = CAST(GETDATE() + 1 - DATEPART(DAY, GETDATE()) AS DATE)
SELECT COUNT(Filler)
FROM FK
WHERE FK.DT = CAST(DATEADD(m, DATEDIFF(m, 0, getdate()), 0) AS DATE)
OPTION (QUERYTRACEON 4199)
Geef dit plan
Vanwege de veel nauwkeurigere kardinaliteitsschattingen doet het plan nu slechts een enkele indexzoekactie in plaats van een volledige scan.