Posiadamy hurtownię danych z dość dużą liczbą rekordów (10-20 milionów wierszy) i często uruchamiamy zapytania, które zliczają rekordy między określonymi datami lub liczą rekordy z określonymi flagami, np.
SELECT
f.IsFoo,
COUNT(*) AS WidgetCount
FROM Widgets AS w
JOIN Flags AS f
ON f.FlagId = w.FlagId
WHERE w.Date >= @startDate
GROUP BY f.IsFoo
Wydajność nie jest okropna, ale może być stosunkowo powolna (może 10 sekund na zimnej pamięci podręcznej).
Ostatnio odkryłem, że mogę używać GROUP BYw widokach indeksowanych, więc wypróbowałem coś podobnego do następującego
CREATE VIEW TestView
WITH SCHEMABINDING
AS
SELECT
Date,
FlagId,
COUNT_BIG(*) AS WidgetCount
FROM Widgets
GROUP BY Date, FlagId;
GO
CREATE UNIQUE CLUSTERED INDEX PK_TestView ON TestView
(
Date,
FlagId
);
W rezultacie wydajność mojego pierwszego zapytania wynosi teraz <100ms, a wynikowy widok i indeks <100k (chociaż nasza liczba wierszy jest duża, zakres dat i identyfikatorów flag oznacza, że ten widok zawiera tylko 1000-2000 wierszy).
Pomyślałem, że może to spowolni wydajność zapisu w tabeli widżetów, ale nie - wydajność wstawiania i aktualizacji w tej tabeli jest praktycznie niezmieniona, o ile mogłem powiedzieć (a ponadto, jako hurtownia danych, ta tabela jest rzadko aktualizowana tak czy inaczej)
Wydaje mi się to zbyt piękne, aby mogło być prawdziwe - prawda? Na co muszę uważać, korzystając z indeksowanych widoków w ten sposób?
SELECTiCREATE VIEWskrypty są błędne, ponieważ uważam, że to twójCREATE INDEXskrypt.