Charlieface's questions

给出以下两个表：

CREATE TABLE SalesLedger (
  Id int PRIMARY KEY IDENTITY,
  Date date NOT NULL,
  Total decimal(38,18),
  INDEX IX (Date, Total)
);

CREATE TABLE Purchases (
  Id int PRIMARY KEY IDENTITY,
  Date date NOT NULL,
  Total decimal(38,18),
  INDEX IX (Date, Total)
);

以及下面的视图

CREATE VIEW ViewMetrics
AS

Select
  Date,
  'Sale' as Metric,
  Total as Value
From SalesLedger

UNION ALL

Select
  Date,
  'Purchase' as Metric,
  Total as Value
From Purchases;

以下查询使用一Concatenation Sort对：

Select SUM(Value) as Sales, Date
from ViewMetrics
Group By Date;

粘贴计划

而较小的重写可以明显提高性能Merge Concatenation

SELECT SUM(Sales), Date
FROM (
  Select SUM(Value) as Sales, Date
  from ViewMetrics
  Group By Metric, Date
) t
GROUP BY Date;

粘贴计划

编译器可以清楚地看到视图是按 分区的Metric，正如这个查询所示，不需要Sort：

Select SUM(Value) as Sales, Date
from ViewMetrics
where Metric = 'Sale'
Group By Date;

问题是：为什么第一个查询强制 a Sort，而第二个查询可以使用更有效的Merge Concatenation，因为在这两种情况下该Metric列都没有WHERE谓词？

Merge鉴于索引已经排序Date并且分区已打开，编译器是否应该能够看到 a可以工作Metric？或者如果它看不到这一点，为什么GROUP BY Metric, Date突然赋予它这种能力？

数据库<>小提琴

更奇怪的是，正如 @MartinSmith 发现的那样，如果没有数据，那么编译器将使用更好的计划，尽管没有中间聚合Metric, Date。db<>fiddle另一方面，没有部分聚合的合并可能比部分聚合后的排序慢，因为有更多的行需要合并。问题是为什么它不能默认同时进行部分聚合和合并？

我猜测当聚合包含分区时，分区视图有一些特定的优化，因为在这种情况下它使用串联，并且当需要排序时它使用合并串联，请参阅 db<> fiddle。当您想要进一步聚合时，这会有所帮助，因为数据现在已经按正确的顺序排序。但是，如果您不进行中间聚合，它就没有应用它的逻辑。

长话短说；博士； SQL Server 允许标量 UDF 在模式绑定时递归调用自身，但仅当使用语法更改为这样做时，这是一个错误吗CREATE OR ALTER？还是不允许其他语法的错误？

一个简单的递归标量 UDF 可以构造如下

CREATE FUNCTION dbo.Try1 (@i int)
RETURNS int
AS BEGIN
  RETURN IIF(@i = 0, 0, @i + dbo.Try1(@i - 1));
END;

只要这不是模式绑定的，那么这是允许的。

让我们尝试对其进行模式绑定，我们会做

CREATE FUNCTION dbo.Try2 (@i int)
RETURNS int
WITH SCHEMABINDING
AS BEGIN
  RETURN IIF(@i = 0, 0, @i + dbo.Try2(@i - 1));
END;

没有。

Cannot find either column "dbo" or the user-defined function
or aggregate "dbo.Try2", or the name is ambiguous

在没有递归的情况下创建它然后改变它

CREATE OR ALTER FUNCTION dbo.Try3 (@i int)
RETURNS int
WITH SCHEMABINDING
AS BEGIN RETURN NULL; END;

ALTER FUNCTION dbo.Try3 (@i int)
RETURNS int
WITH SCHEMABINDING
AS BEGIN
  RETURN IIF(@i = 0, 0, @i + dbo.Try3(@i - 1));
END;

这次是一个不同的错误：

Cannot schema bind function 'dbo.Try3' because name 'dbo.Try3' is invalid
for schema binding. Names must be in two-part format
and an object cannot reference itself.

嗯，an object cannot reference itself这个规则是谁发明的？它不在文档中。

让我们试试CREATE OR ALTER

CREATE OR ALTER FUNCTION dbo.Try4 (@i int)
RETURNS int
WITH SCHEMABINDING
AS BEGIN
  RETURN IIF(@i = 0, 0, @i + dbo.Try4(@i - 1));
END;

还没。

但是，如果我们首先CREATE 不使用递归，然后使用CREATE OR ALTER（不 ALTER）使用递归，那么它就可以工作

CREATE OR ALTER FUNCTION dbo.Try5 (@i int)
RETURNS int
WITH SCHEMABINDING
AS BEGIN RETURN NULL; END;

CREATE OR ALTER FUNCTION dbo.Try5 (@i int)
RETURNS int
WITH SCHEMABINDING
AS BEGIN
  RETURN IIF(@i = 0, 0, @i + dbo.Try5(@i - 1));
END;

CREATE OR ALTER奇怪的是：无论哪种方式在下面起作用，这都没有意义。如果它真的丢弃并重新创建，那么为什么我们不得到第一个错误？如果它改变了，那么为什么最后一个选项有效？

最有趣的是：如果我们先在没有模式绑定的情况下创建它，那么CREATE OR ALTER WITH SCHEMABINDING我们就会得到

Cannot schema bind function 'dbo.Try6'. 'dbo.Try6' is not schema bound.

这完全是胡说八道。

数据库<>小提琴

TL;博士;

给定一个索引视图，该视图在JOIN两个表之间具有一个外键关系以及父表上的谓词。 当插入外键的父表时，编译器将索引维护添加到计划中，即使可以证明不存在匹配的行。WHERE

这是一个错误，还是错过了优化？或者我是否存在一些逻辑或代数谬误？

设置

CREATE TABLE Parent (Id int identity primary key, SomeCol bit not null, OtherCol int not null);

CREATE TABLE Child (Id int identity primary key, ParentId int not null references Parent (Id) INDEX IX_Parent NONCLUSTERED);

CREATE VIEW dbo.vChild
WITH SCHEMABINDING
AS
SELECT c.Id, c.ParentId
FROM dbo.Child c
JOIN dbo.Parent p ON p.Id = c.ParentId
-- WHERE p.SomeCol = 0;  -- problem dependent on this line

CREATE UNIQUE CLUSTERED INDEX CX_vChild ON vChild (Id)

db<>fiddle with WHERE
db<>fiddle without WHERE

在这个阶段，UPDATE视图中的任何影响列以及视图表中的任何一个DELETE都非常正确地触发视图维护。编译器将获取修改后的行，将它们汇总并通过视图的连接提供它们，将任何结果输出到视图的索引中。

对于对 的插入也可以这样说Child，因为可能已经存在一行Parent（符合WHERE），因此新Child行可能符合联接的条件。

问题

插入时Parent，证明不需要做索引维护。由于外键关系，匹配行还不能存在Child，因此插入中没有符合视图条件的行。

如果您要运行以下脚本，您将看到未完成任何视图维护。

INSERT Parent (SomeCol, OtherCol)
VALUES (0, 100);

粘贴计划

很明显，编译器可以推断这里不需要视图维护。

但是，如果您WHERE p.SomeCol = 0在视图定义中取消注释该行，您会突然得到视图维护。因此，向视图添加另一列，它不是连接列并且没有外键关系，会导致这种情况。尽管应用了相同的关系逻辑：插入仍然应该证明不符合视图的条件，因为外键列仍然存在。

粘贴计划

奇怪的是，编译器仍然可以识别插入不符合视图条件的某些情况（尽管这个特定示例是自动参数化的）。

在这里，编译器识别SomeCol失败WHERE，并且不需要进行索引维护。

INSERT Parent (SomeCol, OtherCol)
VALUES (1, 100);

粘贴计划