Snowflake存储计算差异及克隆库存储占用核查问题

一、表Size与Account Usage存储量差异巨大的原因 #

这种差异核心在于两者的统计范围和计费逻辑完全不同，具体可以从这几个关键点理解：

• 统计范围的本质区别
  你在表详情页看到的Size（或通过SELECT bytes FROM information_schema.tables WHERE table_name='MYTABLE'查询的字节数）是该表的全量存储占用，包含三部分：

  • 当前活跃的数据版本（日常查询到的内容）
  • Time Travel保留期内的历史数据版本（用于恢复或回溯查询）
  • Fail-safe存储（仅永久表拥有，用于极端故障恢复，保留7天）

  而Account Usage下的存储统计（比如STORAGE_USAGE视图）只计算计费存储量：即活跃数据加上Time Travel保留期内可恢复的历史数据。Fail-safe存储是Snowflake免费提供的，不计入计费，所以这部分不会出现在Account Usage的统计结果里。如果你的表有大量已进入Fail-safe阶段的历史数据，就会导致两者出现GB级的巨大差异。

• 查询条件可能存在误差
  如果你查询Account Usage时过滤条件有误（比如只选了某一天的统计，或者误指定了其他数据库），也可能得到远小于实际表大小的结果。建议检查你的查询语句，确保是针对目标数据库/表的全周期统计。

• 数据同步延迟（可能性极低）
  Account Usage视图的数据同步通常有1-2小时的延迟，但这种情况只会导致小范围差异，不会出现GB级的差距，所以大概率不是这个原因。

二、克隆数据库后如何核查存储空间占用 #

Snowflake的克隆采用**写时复制（Copy-on-Write）**机制：初始克隆的数据库/表不会占用额外的活跃存储，所有数据和原对象共享，只有当克隆对象发生写操作（插入、更新、删除等）时，才会生成新的数据版本并占用额外存储。核查方法如下：

• UI直观查看
  进入克隆后的数据库，逐个查看表的Size列。初始状态下，克隆表的Size会和原表一致，但这只是元数据显示的总逻辑大小，实际物理存储是和原表共享的，不会重复计费。当你修改克隆表的数据后，Size会逐渐增加，增加的部分就是新占用的存储。

• 用Account Usage视图对比统计
  通过DATABASE_STORAGE_USAGE_HISTORY视图对比克隆前后的存储变化：

  SELECT 
    DATE_TRUNC('day', USAGE_DATE) AS usage_day,
    DATABASE_NAME,
    AVG(STORAGE_BYTES)/1024/1024/1024 AS storage_gb
  FROM ACCOUNT_USAGE.DATABASE_STORAGE_USAGE_HISTORY
  WHERE DATABASE_NAME IN ('ORIGINAL_DB', 'CLONED_DB')
  GROUP BY usage_day, DATABASE_NAME
  ORDER BY usage_day;
  

  克隆后如果没有修改数据，两个数据库的总存储量之和不会明显大于原数据库的存储量（因为共享存储）；如果有修改，会看到克隆数据库的存储量逐渐上升，上升的部分就是新增的独立存储。

• 查看克隆对象的独立存储
  使用SHOW CLONES命令可以查看克隆对象的详细信息，其中OWNED_STORAGE_BYTES列会显示克隆对象自己占用的独立存储（不包含共享的原对象存储）：

  SHOW CLONES OF DATABASE ORIGINAL_DB;
  

  初始状态下该值为0，当克隆对象被修改后，数值会随新增存储量上升。

• 表级存储明细查询
  针对克隆后的表，可查询information_schema.tables的bytes和owned_bytes列：

  SELECT 
    table_name,
    bytes/1024/1024/1024 AS total_size_gb,
    owned_bytes/1024/1024/1024 AS owned_size_gb
  FROM information_schema.tables
  WHERE table_schema='YOUR_SCHEMA' AND table_catalog='CLONED_DB';
  

  owned_bytes是该克隆表实际占用的独立存储（与原表不共享的部分），total_size_gb是包含共享部分的逻辑总大小。

内容的提问来源于stack exchange，提问作者Arumugam Kr