我们有一个记录数相当大(10-2000 万行)的数据仓库,并且经常运行查询来计算特定日期之间的记录,或计算具有特定标志的记录,例如
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 毫秒,结果视图和索引 < 100k(尽管我们的行数很大,但日期和标志 ID 的范围意味着该视图仅包含 1000-2000 行)。
我认为这可能会削弱写入 Widget 表的性能,但不会 - 据我所知,插入和更新该表的性能几乎不受影响(另外,作为一个数据仓库,该表不经常更新反正)
对我来说,这似乎好得令人难以置信——是吗?以这种方式使用索引视图时需要注意什么?