💡**题型和时间** — 65 题 / 115 分钟 ≈ 每题 106 秒，比 Core 宽松。但 Advanced 场景题读题时间长（经常有长 SQL 或 query profile 截图），建议第一遍 70 分钟过完 + Mark 不确定的，剩 45 分钟专攻 Mark 题。不要在任何一题上纠结超过 3 分钟。
💡**关键词条件反射** — "低延迟 / 秒级 / Kafka 流" → Snowpipe Streaming；"文件批量 / S3 event notification" → Snowpipe；"声明式增量 + join" → Dynamic Tables；"只追踪 INSERT" → Append-only Stream；"CDC 含 UPDATE/DELETE" → Standard Stream；"精确点查询 substring" → Search Optimization Service；"单表聚合自动刷新" → Materialized View；"remote disk spilling" → 升 warehouse；"partition scanned 100%" → 考虑 Clustering Key。
💡**记死系统函数速查表** — SYSTEM$STREAM_HAS_DATA、SYSTEM$CLUSTERING_INFORMATION、SYSTEM$CLUSTERING_DEPTH、SYSTEM$PIPE_STATUS、SYSTEM$TASK_DEPENDENTS_ENABLE、COPY_HISTORY、PIPE_USAGE_HISTORY、TASK_HISTORY、VALIDATE(table, job_id)。这些函数考试经常直接问"用哪个函数能查 X"。
💡**Query Profile 阅读必练** — 在 trial 账户里故意跑一些 bad query（超大 join、缺 WHERE 条件、warehouse 太小），亲眼看 local vs remote spilling、partitions pruned 的数字，建立直觉。考试一张 profile 截图能秒判断瓶颈这种能力光看 PPT 学不会。
💡**Core 和 Advanced 考点重叠部分不要掉以轻心** — Time Travel、Zero-copy Clone、Secure Data Sharing 这些 Core 考过的内容在 Advanced 里会出"进阶版"题（比如跨账户 Share 的 consumer 能否用 Time Travel 查历史 — 不能）。别以为 Core 过了这些就稳。
💡**关于 Iceberg Tables 和 Hybrid Tables** — 2024-2025 Snowflake 新 GA 的功能陆续进考纲。Iceberg Tables 让 Snowflake 直接读写开放格式的数据湖，Hybrid Tables（Unistore）支持行存 + 事务，对标 OLTP。考前一周刷一遍官方最新 release notes，题库可能还没覆盖。
💡**2 年有效期 + 需要 Core 续期** — Advanced 证书 2 年有效，**且依赖 Core 证书的有效状态** — Core 过期，Advanced 也跟着失效。规划续期时要同时考虑两张证。一个省钱技巧：在 Advanced 到期前考 Recertification 版本或直接考另一张 Advanced（比如 Architect），可以自动刷新所有相关证书有效期。
⚠️**Streams 的变更追踪机制理解错** — Stream 不是"表的副本"也不是"队列"，它是一个**基于 offset 的元数据指针**，指向底层 Time Travel 里的一个时间点。当你 SELECT Stream 时看到的是"自上次消费后"的所有变更。**只有在一个 DML 事务中消费 Stream，offset 才会推进**（比如 INSERT INTO target SELECT * FROM stream 这种语句）。光 SELECT 查看不会推进 offset。另一个致命坑：Stream 的 offset 受 **STALE_AFTER** 保护，默认等于 DATA_RETENTION_TIME_IN_DAYS，**Stream 过期后无法恢复**，需要重建 — 考题常问"Stream 连续 15 天未消费 + 源表 retention 14 天会发生什么"，答案是 Stream 变 STALE，后续读取报错。
⚠️**Task DAG 的依赖和调度理解不到位** — Task Tree 里**只有根 Task 能设置 schedule**（CRON 或 interval），子 Task 通过 AFTER 子句链到父 Task 上，不能自己调度。Task 默认是**串行执行**（父跑完才跑子），想并行需要显式建多个 Task 分支。常见错误：以为在子 Task 上设 schedule 会生效（不会，会报错）。另一个高频错题：**SYSTEM$STREAM_HAS_DATA()** 必须放在 Task 的 **WHEN** 子句里用，不是在 Task body 里 IF，否则空跑也会消耗 credit。Serverless Task 和 User-managed Task（需要指定 warehouse）的计费模型也经常考。
⚠️**Snowpipe 和 Snowpipe Streaming 混为一谈** — 这是两个完全不同的产品。**Snowpipe**（批式）：基于文件，你上传文件到 stage → 事件触发 → Snowpipe 执行 COPY INTO，延迟约 1 分钟，按加载的文件数付费，使用 Snowflake 管理的 serverless 资源。**Snowpipe Streaming**：基于行，通过 Java SDK 或 Kafka Connector 直接写入表，不经过 stage 文件，延迟 **秒级**，按写入行数 + 计算时间付费，使用 client 端资源 + Snowflake 服务端 row buffering。考题会给场景让你选：有"上传 CSV 文件"关键词选批式 Snowpipe，有"Kafka / 实时事件流 / 亚秒级延迟"选 Snowpipe Streaming。它们也可以混用（lambda 架构），但计费和监控接口完全不同。
⚠️**物化视图 vs Dynamic Tables vs Result Cache 选型不清** — **Result Cache**：Cloud Services 层免费的查询结果缓存，24 小时有效，源数据未变时命中，**零成本**但不可控。**物化视图（Materialized View）**：Enterprise Edition 起支持，自动后台刷新，**限制很严**（单表、不支持 joins、不支持 window functions、不支持 UDF），适合对单大表做聚合。**Dynamic Tables**：2023 年 GA 的新特性，**声明式增量计算**，支持 joins 和复杂 SQL，用 TARGET_LAG 控制新鲜度，是 Streams+Tasks 的简化替代。考题最爱出"一个需要 join 两张表 + 5 分钟新鲜度"的场景 — 物化视图做不了（不支持 join），Streams+Tasks 能做但代码复杂，Dynamic Tables 才是最优解。
⚠️**Query Profile 误读导致优化方向错** — Profile 里最容易看错的几个信号：(1) **Local Disk Spilling** 不等于灾难，小量 spilling 正常；但 **Remote Disk Spilling** 几乎肯定是性能杀手，必须立刻升 warehouse 或重写查询。(2) **Partitions Scanned / Partitions Total** 比例接近 100% 不代表一定是坏事（小表本来就全扫），关键看绝对数字 + 扫描字节数。(3) **Exploding Join**（输出行数 >> 输入行数之和）通常是 join key cardinality 没算清楚或有笛卡尔积，不是 warehouse 问题，升 size 没用必须改 SQL。(4) **Bytes sent over the network** 高 → 可能有跨 region 数据传输或 Result Cache miss。考题会给 profile 截图让你二选一"该升 warehouse 还是该改 SQL"，答错直接送分。
⚠️**Clustering Key 的选择误区** — 不是所有表都该加 Clustering Key。选型原则：(1) 表足够大（> 1TB 才值得）；(2) 查询常用这一列做过滤或 join；(3) 列的基数适中（太低如 gender 无效，太高如 uuid 维护成本爆炸）；(4) 数据不是自然按这一列加载的。**AUTOMATIC_CLUSTERING** 开了之后 Snowflake 会后台持续重聚类，消耗 credit — 对写入频繁的表成本可能高于收益。考题爱出"这张表该加 Clustering 吗"的场景，答案经常是 "不加 / 先看 SYSTEM$CLUSTERING_INFORMATION 的 depth"。另一个坑：加 Clustering Key **不会立刻重组历史数据**，需要 ALTER TABLE ... RECLUSTER 或等自动聚类慢慢做。
⚠️**UDF / UDTF / Stored Procedure 的边界混淆** — UDF（标量函数，一行输入一行输出）、UDTF（表函数，一行输入多行输出）、Stored Procedure（过程，可以执行 DML 和事务）三者能做什么不能做什么考试经常细抠。**UDF 不能有副作用**（不能 INSERT / UPDATE），**Stored Procedure 才能**。**EXECUTE AS CALLER vs EXECUTE AS OWNER** 决定了权限检查逻辑 — OWNER 模式下 proc 以创建者权限跑（常用于数据脱敏场景），CALLER 模式下以调用者权限跑。Python Snowpark 的 UDF 装饰器 @udf 和存储过程装饰器 @sproc 别搞混。
⚠️**Time Travel 和 Fail-safe 的对象级配置** — 账户级 DATA_RETENTION_TIME_IN_DAYS 是默认值，**可以在 database / schema / table 级别覆盖**。**MIN_DATA_RETENTION_TIME_IN_DAYS**（账户级）可以强制下限防止用户把表的 retention 改到 0。临时表（TEMPORARY）和 transient 表**没有 Fail-safe**，transient 表 retention 最多 1 天 — 考题会问"创建 transient table 意味着省多少钱"，答案是没有 Fail-safe 的 7 天存储成本。
