（一）前言

（二）具体化视图与标准视图

1. 两者的定义上区别

2. 具体化视图创建方式

（1）语法

（2）参数

（3）注解

（4）示例

（三）使用具体化视图的优点

（四）常见方案

1. 需要提高大规模数据的复杂分析查询的性能

2. 在没有或只有少量查询更改的情况下需要更快的性能

3. 需要不同的数据分布策略来提高查询性能

（一）前言

Azure Synapse 中适用于专用 SQL 池的具体化视图为复杂的分析查询提供一种低维护的方法来加速查询性能，且无需对查询进行任何更改。本文讨论了使用具体化视图的一般指南。

（二）具体化视图与标准视图

1. 两者的定义上区别

Azure Synapse 中的专用 SQL 池支持标准视图和具体化视图。两者都是用 SELECT 表达式创建并以逻辑表的形式呈现给查询的虚拟表。视图封装了常见数据计算的复杂性，并为计算更改添加了一个抽象层，因此无需重写查询。

每次使用标准视图时，该视图都会计算其数据。磁盘上不存储任何数据。用户通常使用标准视图作为一个有助于组织专用 SQL 池中的逻辑对象和查询的工具。若要使用标准视图，查询需要直接引用它。

和表一样，具体化视图在专用 SQL 池中预先计算、存储和维护其数据。每次使用具体化视图时都不需要重新计算。这就是为什么使用具体化视图中的全部或部分数据的查询可以获得更快的性能。更有利的是，查询可以使用具体化视图而无需直接引用它，因此不需要更改应用程序代码。

标准视图上的大多数要求仍然适用于具体化视图。

比较	查看	具体化视图
查看定义	存储在专用 SQL 池中。	存储在专用 SQL 池中。
查看内容	在每次使用视图时生成。	在创建视图期间进行预处理并存储在专用 SQL 池中。随着数据添加到基础表中而更新。
数据刷新	始终更新	始终更新
从复杂查询检索视图数据的速度	慢	Fast
额外存储	否	是
语法	CREATE VIEW	CREATE MATERIALIZED VIEW AS SELECT

2. 具体化视图创建方式

本段落说明如何在 Azure Synapse Analytics 中使用 CREATE MATERIALIZED VIEW AS SELECT T-SQL 语句开发解决方案。

具体化视图会保留从视图定义查询返回的数据，并在基础表中的数据更改时自动更新。它提高了复杂查询（通常是使用联接和聚合的查询）的性能，同时提供了简单的维护操作。由于具体化视图具有执行计划自动匹配功能，因此无需在查询中引用它，优化器即会考虑将此视图作为替换项。通过使用这一功能，数据工程师可以将具体化视图作为改进查询响应时间的机制来实现，而不必再更改查询。

（1）语法

CREATE MATERIALIZED VIEW [ schema_name. ] materialized_view_nameWITH (  <distribution_option>)AS <select_statement>
[;]<distribution_option> ::={  DISTRIBUTION = HASH ( distribution_column_name )  | DISTRIBUTION = ROUND_ROBIN  }<select_statement> ::=SELECT select_criteria

备注

Azure Synapse Analytics 中的无服务器 SQL 池不支持此语法。

（2）参数

schema_name

视图所属架构的名称。

materialized_view_name

视图名称。视图名称必须符合有关标识符的规则。可以选择是否指定视图所有者名称。

分布选项

仅支持 HASH 和 ROUND_ROBIN 分步。

select_statement

具体化视图定义中的 SELECT 列表需要至少满足以下两个条件之一：

SELECT 列表包含聚合函数。
具体化视图定义使用了 GROUP BY，并且 SELECT 列表包括 GROUP BY 中的所有列。在 GROUP BY 子句中最多可以使用 32 列。

具体化视图定义的 SELECT 列表必须包含聚合函数。支持的聚合包括 MAX、MIN、AVG、COUNT、COUNT_BIG、SUM、VAR、STDEV。

具体化视图定义的 SELECT 列表使用 MIN/MAX 聚合时，以下要求适用：

必须使用 FOR_APPEND。例如：

CREATE MATERIALIZED VIEW mv_test2
WITH (distribution = hash(i_category_id), FOR_APPEND)
AS
SELECT MAX(i.i_rec_start_date) as max_i_rec_start_date, MIN(i.i_rec_end_date) as min_i_rec_end_date, i.i_item_sk, i.i_item_id, i.i_category_id
FROM syntheticworkload.item i
GROUP BY i.i_item_sk, i.i_item_id, i.i_category_id

引用的基表出现 UPDATE 或 DELETE 时，将禁用具体化视图。  此限制不适用于 INSERT。    若要重新启用具体化视图，请运行 ALTER MATERIALIZED VIEW 和 REBUILD。

（3）注解

Azure 数据仓库中的具体化视图与 SQL Server 中的索引视图相似。  除了具体化视图支持聚合函数外，它与索引视图适用的限制几乎相同。

备注

尽管 CREATE MATERIALIZED VIEW 不支持 COUNT、DISTINCT、COUNT(DISTINCT expression) 或 COUNT_BIG (DISTINCT expression)，但具有这些函数的 SELECT 查询仍可以从具体化视图中获益，提升性能，因为 Synapse SQL 优化器可以在用户查询中自动重写这些聚合，以匹配现有的具体化视图。有关详细信息，请查看下文中的示例部分。

CREATE MATERIALIZED VIEW AS SELECT 不支持 APPROX_COUNT_DISTINCT。

具体化视图仅支持 CLUSTERED COLUMNSTORE INDEX。

具体化视图无法引用其他视图。

也无法在具有动态数据掩码 (DDM) 的表上创建具体化视图，即使 DDM 列不属于该具体化视图也是如此。如果表列是活动具体化视图或禁用的具体化视图的一部分，则 DDM 无法添加到此列。

无法在启用了行级安全性的表上创建具体化视图。

可以在已分区表上创建具体化视图。    具体化视图基表支持分区 SPLIT/MERGE，不支持分区 SWITCH。

具体化视图引用的表不支持 ALTER TABLE SWITCH。请先禁用或删除具体化视图，然后再使用 ALTER TABLE SWITCH。在以下应用场景中，需要向具体化视图添加新列，才能创建具体化视图：

场景	要添加到具体化视图的新列	评论
具体化视图定义的 SELECT 列表缺少 COUNT_BIG()	COUNT_BIG (*)	通过具体化视图创建自动添加。不需要任何用户操作。
由用户在具体化视图定义的 SELECT 列表中指定 SUM(a)，其中“a”是可为空的表达式	COUNT_BIG (a)	用户需要手动将表达式“a”添加到具体化视图定义中。
由用户在具体化视图定义的 SELECT 列表中指定 AVG(a)，其中“a”是表达式。	SUM(a), COUNT_BIG(a)	通过具体化视图创建自动添加。不需要任何用户操作。
由用户在具体化视图定义的 SELECT 列表中指定 STDEV(a)，其中“a”是表达式。	SUM(a), COUNT_BIG(a), SUM(square(a))	通过具体化视图创建自动添加。不需要任何用户操作。

创建后，SQL Server Management Studio
中的 Azure Synapse Analytics 实例的视图文件夹将显示具体化实体。

用户可以运行 SP_SPACEUSED
和 DBCC PDW_SHOWSPACEUSED
来确定具体化视图占用的空间。还有 DMV 可提供更多可自定义的查询，用于标识占用的空间和行。有关详细信息，可以参考表大小查询
相关知识。

可以通过 DROP VIEW 删除具体化视图。可以使用 ALTER MATERIALIZED VIEW 禁用或重新生成具体化视图。

具体化视图是一种自动查询优化机制。用户不需要直接查询具体化视图。提交用户查询后，引擎将检查用户对查询对象的权限，如果用户没有访问查询中的表或普通视图的权限，引擎将使查询在未执行的情况下失败。如果用户的权限已经过验证，优化器将自动使用匹配的具体化视图来执行查询，以提高性能。无论通过查询基表还是查询具体化视图来执行查询，用户都将获得相同的返回数据。

SQL Server Management Studio 中的 EXPLAIN 计划和图形估计执行计划可以显示查询优化器是否考虑将具体化视图用于查询执行。 SQL Server Management Studio 中的图形估计执行计划可以显示查询优化器是否考虑将具体化视图用于查询执行。

（4）示例

A. 此示例显示 Synapse SQL 优化器如何自动使用具体化视图来执行查询，以获得更好的性能，即使该查询使用的是 CREATE MATERIALIZED VIEW 不支持的函数（例如 COUNT(DISTINCT expression)）也是如此。过去需要几秒钟才能完成的查询现在不到一秒就能完成，而且无需对用户查询进行任何更改。

-- Create a table with ~536 million rows
create table t(a int not null, b int not null, c int not null) with (distribution=hash(a), clustered columnstore index);insert into t values(1,1,1);declare @p int =1;
while (@P < 30)begininsert into t select a+1,b+2,c+3 from t;  select @p +=1;
end-- A SELECT query with COUNT_BIG (DISTINCT expression) took multiple seconds to complete and it reads data directly from the base table a.
select a, count_big(distinct b) from t group by a;-- Create two materialized views, not using COUNT_BIG(DISTINCT expression).
create materialized view V1 with(distribution=hash(a)) as select a, b from dbo.t group by a, b;-- Clear all cache.DBCC DROPCLEANBUFFERS;
DBCC freeproccache;-- Check the estimated execution plan in SQL Server Management Studio.  It shows the SELECT query is first step (GET operator) is to read data from the materialized view V1, not from base table a.
select a, count_big(distinct b) from t group by a;-- Now execute this SELECT query.  This time it took sub-second to complete because Synapse SQL engine automatically matches the query with materialized view V1 and uses it for faster query execution.  There was no change in the user query.DECLARE @timerstart datetime2, @timerend datetime2;
SET @timerstart = sysdatetime();select a, count_big(distinct b) from t group by a;SET @timerend = sysdatetime()
select DATEDIFF(ms,@timerstart,@timerend);

B. 在此示例中，User2 在 User1 拥有的表上创建具体化视图。具体化视图由 User1 拥有。

/****************************************************************
Setup:
SchemaX owner = DBO
SchemaX.T1 owner = User1
SchemaX.T2 owner = User1
SchemaY owner = User1
*****************************************************************/
CREATE USER User1 WITHOUT LOGIN ;
CREATE USER User2 WITHOUT LOGIN ;
GO
CREATE SCHEMA SchemaX;
GO
CREATE SCHEMA SchemaY AUTHORIZATION User1;
GO
CREATE TABLE [SchemaX].[T1] (    [vendorID] [varchar](255) Not NULL, [totalAmount] [float] Not NULL,    [puYear] [int] NULL );
CREATE TABLE [SchemaX].[T2] (    [vendorID] [varchar](255) Not NULL,    [totalAmount] [float] Not NULL,    [puYear] [int] NULL);
GO
ALTER AUTHORIZATION ON OBJECT::SchemaX.[T1] TO User1;
ALTER AUTHORIZATION ON OBJECT::SchemaX.[T2] TO User1;/*****************************************************************************
For user2 to create a MV in SchemaY on SchemaX.T1 and SchemaX.T2, user2 needs:
1. CREATE VIEW permission in the database
2. REFERENCES permission on the schema1
3. SELECT permission on base table T1, T2
4. ALTER permission on SchemaY
******************************************************************************/
GRANT CREATE VIEW to User2;
GRANT REFERENCES ON SCHEMA::SchemaX to User2;
GRANT SELECT ON OBJECT::SchemaX.T1 to User2;
GRANT SELECT ON OBJECT::SchemaX.T2 to User2;
GRANT ALTER ON SCHEMA::SchemaY to User2;
GO
EXECUTE AS USER = 'User2';
GO
CREATE materialized VIEW [SchemaY].MV_by_User2 with(distribution=round_robin)
as select A.vendorID, sum(A.totalamount) as S, Count_Big(*) as T from [SchemaX].[T1] Ainner join [SchemaX].[T2] B on A.vendorID = B.vendorID group by A.vendorID ;
GO
revert;
GO

（三）使用具体化视图的优点

设计合理的具体化视图具有以下优势：

使用联接和聚合函数减少复杂查询的执行时间。查询越复杂，就越有可能节省执行时间。当查询的计算成本很高而生成的数据集很小时，可以获得最大的优势。
专用 SQL 池中的优化器可以自动使用部署的具体化视图来改善查询执行计划。此过程对提供更快查询性能的用户是透明的，并且不需要查询直接引用具体化视图。
需要对视图进行低维护。所有来自基表的增量数据更改将以同步方式自动添加到具体化视图中，这意味着基表和具体化视图在相同事务中进行更新。这种设计可以使查询具体化视图后返回的数据与直接查询基表后返回的数据相同。
具体化视图中的数据可以采用与基表不同的方式分发。
具体化视图中的数据与常规表中的数据具有相同的高可用性和复原优势。

在专用 SQL 池中实现的具体化视图还提供以下优势：

与其他数据仓库提供程序相比，在专用 SQL 池中实现的具体化视图还提供以下优势：

广泛的聚合函数支持。
支持查询特定的具体化视图建议。
根据基表中的数据更改，自动、同步刷新数据。不需要任何用户操作。

（四）常见方案

在以下场景中，往往会使用具体化视图：

1. 需要提高大规模数据的复杂分析查询的性能

复杂的分析查询往往使用更多的聚合函数和表联接，导致更多的计算密集型操作，例如查询执行中的随机排布和联接。因此，复杂的分析查询需要更长时间才能完成，尤其是针对大型表执行时。

用户可以针对从常见查询计算返回的数据创建具体化视图，因此，当查询需要此数据时无需重新计算，从而可以降低计算成本，并加快查询响应速度。

2. 在没有或只有少量查询更改的情况下需要更快的性能

为了支持常规的 ETL 操作和报告，往往会尽量在专用 SQL 池中保留最少量的架构和查询更改。如果查询性能的提高可以弥补视图所产生的成本，则可以使用具体化视图来对查询性能进行优化。

与其他优化选项（例如缩放和统计信息管理）相比，创建和维护具体化视图带来的变化对生产造成的影响更小，并且性能提升的潜力也更高。

创建或维护具体化视图不会影响对基表运行的查询。
查询优化器可以自动使用已部署的具体化视图，而无需在查询中直接引用视图。此功能减少了性能优化中查询更改的需要。

3. 需要不同的数据分布策略来提高查询性能

专用 SQL 池是一种分布式查询处理系统。 SQL 表中的数据使用三种分布策略（哈希、round_robin 或复制）之一分布在多达 60 个节点中。

数据分布在表创建时进行指定，并且在删除表之前保持不变。作为磁盘上的虚拟表，具体化视图支持哈希和 round_robin 数据分布。用户可以选择与基表不同的、但对于使用视图的查询性能最有利的数据分布方式。

Azure Synapse Analytics(Azure SQL DW) 性能优化指南（2）——使用具体化视图优化性能(上)相关推荐

Azure Synapse Analytics (Azure SQL DW)性能优化指南（1）——使用有序聚集列存储索引优化性能
目录 (一)前言 (二)有序与无序聚集列存储索引 (三)查询性能 (四)数据加载性能 (五)减少段重叠 (六)在大型表中创建有序 CCI (六)实战案例 A. 检查有序列和序号: B. 若要更改列序号 ...
Azure Synapse Analytics (Azure SQL DW)性能优化指南（4）——使用结果集缓存优化性能
目录 (一)前言 (二)关键命令 1. 对用户数据库启用/禁用结果集缓存 (1)检查数据库的统计信息设置 (2)为数据库启用查询存储 (3)为数据库启用结果集缓存 (4)检查数据库的结果集缓存设置 ( ...
浅谈用KUSTO查询语言(KQL)在Azure Synapse Analytics(Azure SQL DW)审计某DB账号的操作记录
目录 (一)前言 (二)实际案列 1. 背景说明: 2. 操作步骤 (1)打开Portal (2)搜索"监视器" (3)点击左侧选项卡中的"日志" (4)在新的 ...
Azure Synapse Analytics(Azure SQL DW)中建表语句的注意事项
目录 (一)前言 (二)建表语法 (三)参数说明 1. 列选项 2. 表结构选项 3. 表分发选项 4. 表分区选项 (四)实例 1. 列的示例 (1) 指定一个列排序规则 (2) 指定列的 DEFA ...
Azure Synapse Analytics简介第1部分：什么是Azure Synapse Analytics？
目录数据摄取 Azure Data Lake Storage Gen2 数据探索.训练和服务数据查询服务 Azure Synapse Studio Azure Synapse Notebooks ...
Azure Synapse Analytics简介第3部分：数据科学和商业智能
目录 Power BI集成 Azure机器学习集成聚合不同的数据源样式 Azure Synapse Analytics中的机器学习功能结论在这里,我们讨论并展示了如何使用Azure Synaps ...
BO 4.3支持微软的Azure Synapse Analytics 吗？
微软的Azure Synapse Analytics原名Azure SQL Data Warehouse(以下简称Synapse),是微软推出的一项将企业数据仓库和大数据分析结合在一起按需付费的集成分 ...
MySQL常用优化指南，及大表优化思路（值得收藏）
作者: 低至一折起 juejin.im/post/5b7d52afe51d453885030b91 当MySQL单表记录数过大时,增删改查性能都会急剧下降单表优化除非单表数据未来会一直不断上涨,否 ...
google搜索引擎优化指南_Google谷歌SEO怎么优化？｜新手入门完全指南
虽然国内目前仍然是处于禁用谷歌的状态,但是我知道还是有很大一部分人在日常工作生活中仍然会需要接触到谷歌搜索,尤其是做针对海外市场相关工作及事业的,如海外电商,国际贸易等.那么学习如何为自己的网站做好谷 ...

Azure Synapse Analytics(Azure SQL DW) 性能优化指南（2）——使用具体化视图优化性能(上)

（一）前言

（二）具体化视图与标准视图

1. 两者的定义上区别

2. 具体化视图创建方式

（1）语法

（2）参数

（3）注解

（4）示例

（三）使用具体化视图的优点

（四）常见方案

1. 需要提高大规模数据的复杂分析查询的性能

2. 在没有或只有少量查询更改的情况下需要更快的性能

3. 需要不同的数据分布策略来提高查询性能

Azure Synapse Analytics(Azure SQL DW) 性能优化指南（2）——使用具体化视图优化性能(上)相关推荐

最新文章

热门文章