Snowflake SnowPro Core Certification

**Warehouse sizing 的误区 — 以为"越大越快"** — Warehouse 从 XS 升到 S 计算资源翻倍、成本也翻倍。对小数据量的查询（< 100MB 扫描）升 size 完全没用，瓶颈在 cloud services 层不在计算。考试会给你一个 query profile 让你判断该不该 resize，真正该 resize 的是 warehouse queue 排队时间长或者大表 full scan 慢的场景，小查询慢应该查 clustering 或 pruning。

**Time Travel vs Fail-safe 的时间和恢复方式混淆** — Time Travel：默认 1 天（Standard Edition 只能 1 天，Enterprise+ 最多 90 天），过期前可以用 SELECT ... AT | BEFORE、UNDROP、CLONE 等 SQL 命令自助恢复。Fail-safe：Time Travel 期结束后再保留 **7 天**，**只能联系 Snowflake 技术支持恢复**，用户无法自助操作，也**不能延长**。考题经常混在一起问，记死这两个数字。

**Micro-partition pruning 不理解触发条件** — Snowflake 的 pruning 依赖每个 micro-partition 的元数据（min/max、distinct values）。如果 WHERE 条件用的字段和数据自然排序相关（例如按日期加载的事实表用日期 filter），pruning 效果最好；如果用的是完全随机的字段（例如 uuid），pruning 几乎无效。这时需要定义 **Clustering Key** 手动告诉 Snowflake 按某个字段重组。考试爱出"为什么这个查询扫描了所有分区"。

**角色层级 GRANT 链路搞错** — Snowflake 推荐的角色最佳实践是 ACCOUNTADMIN（账户管理员，不应该日常使用）→ SYSADMIN（应该拥有所有 database/warehouse 的 OWNERSHIP）→ 功能角色（如 DATA_ENGINEER、ANALYST）→ User。SECURITYADMIN 和 USERADMIN 是独立分支，管 role 和 user 的创建。常见错误题：把新创建的 database 直接 grant 给 user 而不是 SYSADMIN，导致 SYSADMIN 反而看不到。记住：**CREATE 出的对象归属创建者当时的 role**，不会自动给上级。

**COPY INTO 和 Snowpipe 的使用场景搞混** — COPY INTO 是**批量**加载命令，你需要手动或定时触发，适合每天/每小时的大批量导入，使用你的 warehouse 的计算资源计费。Snowpipe 是**连续**加载服务，基于 event notification（S3 SQS、Azure Event Grid、GCS Pub/Sub）自动触发，分钟级延迟，使用 Snowflake 管理的 serverless 计算资源，按加载的文件数计费。考题会问"延迟要求 < 5 分钟选什么"（Snowpipe）或"每天凌晨 2 点导入 1 天数据选什么"（COPY INTO + Task）。

**Secure Data Sharing 的计费模型不清楚** — 数据提供方只负责存储成本，不为消费方的查询付费；消费方必须有自己的 Snowflake 账户和 warehouse 才能查询共享数据，付自己的计算费用。如果消费方没有 Snowflake 账户，提供方可以创建 **Reader Account**（提供方付所有成本，消费方只读）。Secure Share **不复制数据**，是通过元数据指针跨账户直接读取。

**Zero-copy Clone 的误解** — CLONE 一个几 TB 的 database 秒级完成、初始不占任何新存储，因为只复制了元数据指针。但是一旦克隆后你在克隆或源上做了 INSERT/UPDATE/DELETE，**只有发生变化的 micro-partitions 才会产生新存储**（写时复制）。考题常问"克隆后立刻占多少存储" — 答案是接近 0，不是源大小。