天蓝色突触分区表 - 没有性能提升答案

【问题标题】：azure synapse partition table - no performance improvement天蓝色突触分区表 - 没有性能提升
【发布时间】：2021-04-23 00:20:21
【问题描述】：

我们有 3 亿行并不断增加的突触表之一。每行作为状态列，即 active_row 0 或 1。 Active_row 是 int 数据类型。用户仅查询基于 active_row = 1 的只有 2800 万行和其余数据，即 2.7 亿是非活动的。为了提高性能并避免对 active_row 进行全表扫描，我将 active_row 分区表中的表转换如下

CREATE TABLE [repo].[STXXXXX]
WITH
(
    DISTRIBUTION = ROUND_ROBIN,
    CLUSTERED INDEX (
        [ID] ASC
    ),
     PARTITION
    (
        active_Row RANGE LEFT FOR VALUES  (0,1)
        )
)
as
select * from repo.nonptxx;

用户报告移动到分区表后没有性能提升。当我检查以下查询时，即分区与非分区时，我看不到查询中有任何差异，可以简单地解释估计的子树、操作等，并且所有统计信息都保持不变。从 sys.dm_pdw_nodes_db_partition_stats 我可以看到在分区 1 上创建的 3 个分区有 2.7 亿个数据溢出到 60 个节点中，60 个节点的分区 2 溢出了 3000 万个数据，60 个节点的分区 3 是空的。

select * from  [repo].[STXXXXX] where active_row =1

对

select * from repo.nonptxx where active_row =1

请指教出了什么问题，为什么移入分区表后没有改善，如何调优？

【问题讨论】：

标签： sql azure-synapse azure-sql-data-warehouse

【解决方案1】：

统计数据更新了吗？

运行 UPDATE STATISTICS [schema_name].[table_name] 并重新运行您的测试（或者，如果它们不存在，则创建 Stats）。

在 Get 步骤之后，当查询 tsql 查询计划中的单个分区时，您应该会看到一个 Filter 步骤，其中返回的行数较少。您不会在 dsql 查询计划中看到它。您不会看到 Select * 的任何子树成本，它转换为来自各个节点的单个 Return 操作，但是您会看到每次执行的估计行数在按分区过滤时会变小（w/stats 是最新的） .缺少或过时的统计信息可能会产生一些奇怪的查询计划结果，因为优化器本质上没有足够的信息来做出正确的决定……因此无法预测，有时结果很差。

如果它不能为您提供所需的性能，您可能需要考虑的另一个选项是保留不带分区的数据并简单地在列上创建一个非聚集索引。索引并不总是被使用或表现得与您对 SQL 服务器的期望完全一样，但是在这种用例中，通常单列索引将极大地提高性能。索引的好处是，如果您将数据从活动移动到非活动，则不需要在物理分区之间移动记录。

【讨论】：