Azure Synapse同DDL同数据跨实例表大小差异排查

核心排查逻辑 #

你通过CSV导出重导入得到的17GB，是1800万行数据在Synapse专用SQL池列存压缩下的标准正常体积，生产环境52GB的异常膨胀和数据内容、DDL、DWU规格无关，优先按以下顺序排查：

• 查列存索引碎片状态
  用以下DMV查询生产环境该表的列存行组物理状态，普通查询权限即可执行，不需要表的写权限：

  SELECT 
      rg.state_desc,
      rg.total_rows,
      rg.deleted_rows,
      rg.size_in_bytes
  FROM sys.dm_pdw_nodes_db_column_store_row_group_physical_stats rg
  JOIN sys.pdw_nodes_tables t ON rg.object_id = t.object_id AND rg.pdw_node_id = t.pdw_node_id
  JOIN sys.pdw_table_mappings m ON t.physical_name = m.physical_name
  JOIN sys.tables tb ON m.object_id = tb.object_id
  WHERE tb.name = '你的异常表名'
  

  正常的列存压缩行组单组应接近100万行、deleted_rows占比<1%，如果查询结果显示存在大量total_rows<10万的小行组、deleted_rows占比超过20%、存在大量TOMBSTONE状态的残留行组，就是长期增删改、小批量插入导致的列存碎片，这是这类体积膨胀的最常见诱因。
• 核对空间分配口径
  执行sp_spaceused '你的异常表名';，对比返回的reserved（已分配空间）和data（实际数据占用空间）字段，如果reserved值远大于data值，说明表存在大量预分配后未释放的空闲区——通常是历史上大批量导入数据后删除、截断操作未回收存储空间导致。
• 检查冗余功能占用
  确认生产环境该表是否开启了系统版本化时态表、CDC变更捕获功能：这类功能会自动生成关联的历史存储表，部分统计口径会将关联表的占用算入主表体积，若保留周期配置过长，过期历史数据会占用数倍于主表的空间。同时核对两个环境表的索引配置，确认生产环境没有被误改为行存堆表、聚集B树索引，或者列存索引配置了过大的压缩延迟导致热数据长期停留在未压缩的增量存储中。

可落地修复方向 #

• 优先执行全表索引重建
  确认业务低峰期执行以下命令，重建列存索引会自动合并小行组、清理墓碑数据、回收空闲空间，90%以上的这类碎片问题重建完成后表体积会回落到17GB左右的正常水平，关联存储过程的扫描效率会有3-5倍的提升：

  ALTER INDEX ALL ON [你的异常表名] 
  REBUILD WITH (MAXDOP = 1, DATA_COMPRESSION = COLUMNSTORE);
  

• 清理冗余残留数据
  若确认存在时态表、CDC的过期历史数据，按业务允许的保留周期清理历史记录，关闭不需要的变更跟踪功能。
• 配置常态化维护规则
  针对生产环境所有百万行以上的大表，配置1-2周一次的定期索引重建、统计信息更新任务；批量导入数据时控制单批次数据量>10万行，避免小批量写入持续产生列存碎片。

内容的提问来源于stack exchange，提问作者Ken Masters