相关疑难解决方法(0)

在我之前的一个问题中，在向表中添加新的计算列时禁用锁升级是个好主意吗？，我正在创建一个计算列：

ALTER TABLE dbo.tblBGiftVoucherItem
ADD isUsGift AS CAST
(
    ISNULL(
        CASE WHEN sintMarketID = 2 
            AND strType = 'CARD'
            AND strTier1 LIKE 'GG%' 
        THEN 1 
        ELSE 0 
        END
    , 0) 
    AS BIT
) PERSISTED;

计算列是PERSISTED，并且根据计算列定义(Transact-SQL)：

坚持

指定数据库引擎将计算值物理存储在表中，并在计算列所依赖的任何其他列更新时更新值。将计算列标记为 PERSISTED 允许在确定性但不精确的计算列上创建索引。有关更多信息，请参阅计算列上的索引。任何用作分区表的分区列的计算列都必须显式标记为 PERSISTED。当指定 PERSISTED 时，computed_column_expression 必须是确定性的。

但是当我尝试在我的列上创建索引时，我收到以下错误：

CREATE INDEX FIX_tblBGiftVoucherItem_incl
ON dbo.tblBGiftVoucherItem (strItemNo) 
INCLUDE (strTier3)
WHERE isUsGift = 1;

无法在表 'dbo.tblBGiftVoucherItem' 上创建过滤索引 'FIX_tblBGiftVoucherItem_incl'，因为过滤器表达式中的列 'isUsGift' 是计算列。重写过滤器表达式，使其不包含此列。

如何在计算列上创建过滤索引？

或者

有替代的解决方案吗？

我有一个带有多个连接的查询，它需要很长时间才能返回一个日期的数据。我已经创建了一个索引视图。在创建视图和索引时，我适当地设置了所有必需的选项。

我想利用索引视图的优势，如果我在其他地方有类似的查询或完全相同的查询，查询优化器会选择索引视图，以便提高性能。我尝试使用用于创建索引的完全相同的查询（带有额外的日期过滤器），但查询计划似乎没有改变。即使我在查询中显式使用视图，视图上的索引仍未使用。我只能让查询优化器使用带有 noexpand 提示的索引。请注意，我使用的是 SQL Server 企业版。

有什么建议？

我们正在使用在 SQL Server Enterprise 上运行的供应商应用程序，它COUNT在处理大多数财务文档（订单、发票等）时在 Items 表上执行语句有一个相当烦人的怪癖。

例如 SELECT COUNT('A') FROM [dbo].[Items] T0

我相信这通常没问题，但是有超过 600 万条记录，并且需要大约 400 毫秒来计算它们。这可能构成整个处理时间的很大一部分。

该表已经有一个非常窄的非聚集索引（tinyint，加上聚集键），这是 SQL 在执行表扫描时使用的，所以我认为我们在这方面不能做得更好。

我知道有一些解决方案，如果可能，我们希望避免：

• 索引视图使用 COUNT_BIG(*)
• 使用更快的处理器——我们使用的是云服务器，这方面的选择非常有限。
• 删除记录 - 在这种情况下不是一个真正的选择。

我们还有其他选择可以加快速度吗？

这是显示设置的要点：https : //gist.github.com/elvishfiend/5094f120b14f8ecfb325623edcb5f3eb

部分出于好奇，我想知道是否可以使用索引（物化）视图来加速对某个基表的计数查询。

查询类似于

SELECT COUNT(*)
FROM BaseTable
WHERE Slot = ?;

所以我创建了一个视图

CREATE VIEW IndexedView
WITH SCHEMABINDING AS
SELECT bt.Slot, COUNT_BIG(*) AS COUNT
FROM dbo.BaseTable bt
GROUP BY bt.Slot;

有聚集索引

CREATE UNIQUE CLUSTERED INDEX IX_Main
ON IndexedView (Slot);

这有效，我现在可以将原始查询编写为

SELECT COUNT
FROM IndexedView
WHERE Slot = ?

并更快地获得所需的结果。

唉，这对我来说没什么用，因为我的查询通常不是手工制作的。我真的需要通过使用索引视图作为某种索引来使原始查询变得更快BaseTable- 我想我在某处读到这可能在某些情况下发生，但根据我的测试，而不是在这个测试中。

所以我的问题是：

• 在这种情况下，索引视图还能以某种方式帮助我吗？
• 任何人都可以推荐来源/文献而不是解释在哪些情况下索引视图确实用于优化它们所基于的表的查询？

编辑：关于重复的问题 - 我对 GROUP BY 和索引视图的聚合方面更感兴趣。答案帮助我找到了我犯的一个愚蠢的错误，现在它也对我有用。

JOYOUS ADDENDUM：现在我让它工作了，我成功地测试了它甚至可以在查询包含左联接的情况下工作，而在这些情况下，左联接实际上可以被优化掉（即 on-clause 涵盖了一个唯一索引在连接表中）。

这真的很棒，因为这意味着即使在带有左连接的查询的情况下，也可以以这样一种方式设计模式，即快速获取所有内容或特定分组的总行数。

我有一个视图，它有一个聚集索引和其他非聚集索引。

SELECT即使我选择了一个索引列，一个简单的查询也不使用任何索引。

这可能是什么原因？

我在 Windows NT 6.1 (Build 7600) 上使用 Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 企业版