sql-server – 为聚合使用索引视图 – 太好了,不是真的吗？

我们有一个数据客栈,其记录数目相等大(1000万到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毫秒,功效视图& index是< 100k(尽量我们的行数很大,但日期和符号ID的范畴意味着此视图仅包括1000-2000行). 我以为这也许会粉碎写入Widget表的机能,可是没有 – 就我所知,插入和更新到这个表的机能险些不受影响(其它,作为数据客栈,这个表很少更新无论怎样) 对我来说,这看起来好得令人难以置信 – 是吗？以这种方法行使索引视图时必要留意什么？

办理要领

这不是太好,不行能.您正在行使索引视图来确切地行使它们 – 可能至少是一种最有用的要领：在写入时付出未来的查询聚合.当功效比源小得多时,这种要领结果最好,虽然,比基本数据更新时更频仍地哀求聚合(凡是在DW中比OLTP更常见).

不幸的是,很多人以为索引视图是神奇的 – 索引不会使全部视图更有用,尤其是简朴地毗连表和/或发生与源沟通数目的行(乃至是乘法)的视图.在这些环境下,视图中的I / O与原始查询沟通乃至更差,不只由于存在沟通或更多行,并且凡是它们也存储和实现更多列.因此,提前实现这些并不会带来任何甜头,由于 – 纵然行使SSD – I / O,收集和客户端处理赏罚/泛起如故是将大型功效集返回给客户端的首要瓶颈.与您仍在行使的全部其他资源对比,在运行时停止毗连所节减的本钱是无法权衡的.

与非聚积索引一样,请留意不要太过执行.假如向一个表添加10个差异的索引视图,您将看到对事变负载的写入部门的更多影响,尤其是在分组列不在(在)聚集密钥中时.

天哪,我一向想写关于这个话题的博客.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!