У нас есть хранилище данных с довольно большим количеством записей (10-20 миллионов строк), и мы часто выполняем запросы, которые подсчитывают записи между определенными датами или подсчитывают записи с определенными флагами, например
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
Производительность не ужасная, но может быть относительно вялой (возможно, 10 секунд на холодном кэше).
Недавно я обнаружил, что могу использовать GROUP BY
в индексированных представлениях, и поэтому попробовал нечто похожее на следующее
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
);
В результате производительность моего первого запроса теперь <100 мс, а результирующее представление и индекс <100 тыс. (Хотя количество строк у нас большое, диапазон дат и идентификаторов флагов означает, что это представление содержит только 1000-2000 строк).
Я думал, что, возможно, это подорвет производительность записи в таблицу Widget, но нет - насколько я могу сказать, производительность вставок и обновлений в эту таблицу практически не зависит (плюс, будучи хранилищем данных, эта таблица обновляется нечасто). так или иначе)
Мне это кажется слишком хорошим, чтобы быть правдой - не так ли? С чем мне следует быть осторожным при использовании индексированных представлений таким образом?
SELECT
иCREATE VIEW
сценарии не правы, так как я считаю, что вашCREATE INDEX
сценарий.