主页 / dba / 问题 / 230121
Accepted
Geezer
Asked: 2019-02-20 02:11:48 +0800 CST

批处理模式是否仅适用于 ColumnStore 索引上的聚合函数

  • 772

Azure SQL 数据库 - 标准版（S3 服务层级）

为什么批处理模式只有在使用聚合函数时才会生效？

DROP TABLE IF EXISTS dbo.TransCS

CREATE TABLE dbo.TransCS (
     Col1 INT 
    ,Col2 AS Col1*2
)
CREATE CLUSTERED COLUMNSTORE INDEX CS_TransCS on dbo.TransCS;

WITH
    L0   AS(SELECT 1 AS c UNION ALL SELECT 1),
    L1   AS(SELECT 1 AS c FROM L0 AS A CROSS JOIN L0 AS B),
    L2   AS(SELECT 1 AS c FROM L1 AS A CROSS JOIN L1 AS B),
    L3   AS(SELECT 1 AS c FROM L2 AS A CROSS JOIN L2 AS B),
    L4   AS(SELECT 1 AS c FROM L3 AS A CROSS JOIN L3 AS B),
    L5   AS(SELECT 1 AS c FROM L4 AS A CROSS JOIN L4 AS B),
    Nums AS(SELECT ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) 
    AS n FROM L5)
INSERT INTO dbo.TransCS (Col1)
SELECT TOP (1000000) n FROM Nums ORDER BY n;

插入 100 万行

行处理

SELECT * FROM dbo.TransCS

执行计划

批量处理

SELECT Col1, Col2, SUM(Col2)OVER ()
FROM dbo.TransCS

执行计划

有没有办法在不使用 Agg 函数的情况下利用性能优势？这方面的文档很薄。

sql-server performance

1 个回答

  1. Best Answer

    背景

    早在 2017 年 7 月，Niko就SQL Server 2017 中的一项更改发布了博客

    ...在 SQL Server 2017 中，查询优化器有一个内部优化，它将对具有 Columnstore 索引的执行计划应用 FULL 优化，避免在行执行模式下执行它们的陷阱

    在此之前，即使涉及到列存储对象，您也会以行模式执行“琐碎的计划”。

    您共享的执行计划显示第一个查询存在此问题，您可以在 XML 中确认：

    StatementOptmLevel="TRIVIAL"

    解决方法

    解决此问题、获得完全优化并从而获得批处理模式扫描的一种方法是添加一个不会影响结果的子查询，如下所示：

    SELECT * FROM dbo.TransCS WHERE (SELECT 1) = 1;

    由于聚合函数，第二个查询已经得到完全优化。

    为什么会这样？

    为什么会发生这种情况，我想到的唯一事情是：

    • 您的数据库的兼容性级别为 130 或更低（这似乎不太可能，因为我可以在执行计划中看到正在使用 140 基数估计器）
    • 这是 Azure SQL 数据库中的一个变化/回归
      • 执行计划中指示的“构建”是15.0.1100.504，它看起来像 SQL Server 2019 构建号（这是有道理的，因为这是 Azure）。我没有要测试的 2019 实例，但行为的变化也可能存在

    您可能希望在反馈网站上将此报告给 Microsoft 。

    • 3

相关问题