Azure Synapse Dedicated Pool中Clustered/Nonclustered Index咨询

与传统SQL Server索引的逻辑异同 #

Synapse专用池的聚簇索引、非聚簇索引在基础组织逻辑上和传统SQL Server保持一致，但针对分布式架构做了适配改造，并非完全照搬单机实现：

• 聚簇索引的物理结构：确实是按指定键列排序的行格式存储，是表的物理存储载体，不会像堆表那样无序列存放。区别在于，Synapse的聚簇索引排序逻辑是在每个独立分布数据库内部维护的，全局层面不做跨分布的排序协同。
• 非聚簇索引的组织逻辑：确实是额外维护的有序索引结构，仅存储索引键列、对应行的定位引用。和单机SQL Server的差异是，建在聚簇行存表上的非聚簇索引，引用值为对应行的聚簇键值；建在堆表上的非聚簇索引，引用值为堆行的物理位置ID。

行存聚簇索引的分析查询性能表现 #

如果是面向大范围扫描、多表关联、聚合计算的典型分析类查询，聚簇行存结构的性能会显著低于同规模的聚簇列存表：

• 行存结构按整行拼接存储，扫描大范围数据时需要读取大量和查询无关的列块，无法像列存结构那样按需读取目标列的高压缩块，IO开销会高出数倍到数十倍。
• 聚簇行存的性能优势仅存在于高选择性的点查/极小范围行检索场景，比如按精准条件返回1-100行结果的查询。这类场景下，列存结构需要跨多个行组、列块定位数据的固有开销会高于聚簇行存顺着排序索引直接定位的开销。只要查询涉及数千行以上的扫描范围，列存结构的性能就会快速反超。

列存与行存结构的共存规则与存储开销 #

• 首先明确硬限制：Synapse专用池的单表仅能有一种物理聚簇存储结构，无法在同一张表上同时创建聚簇列存和聚簇行存索引。聚簇索引是表的物理存储载体，每张表仅能存在一个聚簇结构，你可以选择聚簇列存、聚簇行存、堆表三者之一作为主存储形态，不存在同时拥有列存和行存双主存储的可能。
• 关于重复存储的场景：当在聚簇列存表上创建非聚簇索引时，确实会生成额外的存储副本——这份非聚簇索引是行格式结构，存储非聚簇键列、列存行的定位引用（行组ID、列块内行位置），此时表的存储分为两部分：一部分是列存格式的主表，一部分是行格式的非聚簇索引结构。
• 这类非聚簇索引的额外存储空间通常为原列存表大小的10%-30%（具体数值取决于索引列数量、数据压缩率），且在数据加载、更新、删除操作时需要同步维护行格式的非聚簇结构，会直接拉长数据处理的耗时，这也是官方文档提示“新增索引会占用额外空间、提升数据加载耗时”的根本原因。
• 这类非聚簇索引的设计初衷，是在保留列存大表分析性能的前提下，为高频的点查请求提供加速路径，避免为了少量点查需求把整表切换为行存结构损失全局分析性能。

内容的提问来源于stack exchange，提问作者Bartosz Konieczny