Salesforce Certified Data Architect

**Skinny Table vs Custom Index 的使用场景混淆** — 两者都是 LDV 查询优化手段，但机制完全不同。**Skinny Table** 是 Salesforce 在后台为你创建一份"瘦"副本表，只包含你指定的少量字段（最多 100 个），查询时自动 join 这张副本避免读主表——适合**报表和 list view 反复查询同一批字段**的场景。Skinny Table **必须通过 Salesforce Support 开 Case 创建**，不能自己配，且不支持 multi-select picklist / long text area / encrypted text 字段。**Custom Index** 是在某个字段上建索引加速 WHERE 过滤——适合**某个字段经常被用在 WHERE 条件里**的场景。核心区分：Skinny Table 优化"读取哪些列"，Custom Index 优化"定位哪些行"。考试场景题会让你根据"频繁报表查询 vs 按字段过滤查询"选择对应方案。

**Big Object vs External Object vs Standard Custom Object 的选型搞不清** — 这三者是 LDV 数据归档的核心选项，差异巨大。**Standard Custom Object**：能参与所有 Salesforce 功能（Trigger / Workflow / Flow / Report / Sharing / Validation Rule），但占用 data storage，不适合放几亿行历史数据。**Big Object**：用于 Salesforce 平台内部存储**几十亿行数据**（Archive / Audit Trail 场景），**不占用常规 data storage**（单独计费），但**不支持 Trigger / Workflow / Flow / Standard Report**，只能用 **Async SOQL** 查询（查询结果异步返回到 Chatter 或另一个 Object），不参与 Sharing Rule。**External Object**：通过 **Salesforce Connect（OData 协议）**实时连接外部系统（SAP / Oracle / S3），**数据不存在 Salesforce 里**，每次访问都走外部 API，不算 storage，但**不参与 Sharing Rule、不能加 Trigger、每次访问有延迟**，且有 API 调用限制。考试会给你场景："需要归档 5 年以上的历史订单数据，每月查询不超过 10 次"——答案是 Big Object（数据量大 + 查询频率低 + 不需要 Trigger）。

**Data Skew 的三种类型混为一谈** — Account Skew / Ownership Skew / Lookup Skew 是完全不同的三个问题，考试会分开考。**Account Skew**：超过 **10,000 个 child 记录**（通常是 Contact / Opportunity / Case）挂在同一个 Account 下。问题：父 Account 更新时需要级联更新所有 child 的 sharing，导致 record locking 和漫长的 sharing recalculation。解决：把 skew 账户拆开，或者用 "catch-all" account 时把它放到一个专门的 Role 顶端。**Ownership Skew**：超过 **10,000 条记录 Owner 是同一个 User**（通常是 integration user 或 default owner）。问题：这个 User 的 Role 一改动，sharing recalculation 会持续数小时甚至锁住整个 Org。解决：把 integration user 放到 Role Hierarchy 最顶端（上面没有 Role 就不触发递归），或者多用几个 user 分散 ownership。**Lookup Skew**：Custom Object 的 **Lookup 字段指向同一个父记录超过 10,000 次**。问题：并发更新 child 记录时会频繁锁父记录导致 row lock errors。解决：把 lookup 打散到多个父记录，或者优化业务流程避免并发。**混淆这三种是考试最高频的扣分点**。

**Lookup vs Master-Detail 在 LDV 场景下的权衡反了** — 常规知识告诉你 Master-Detail 有级联删除、Roll-up Summary、子记录继承父记录 Sharing。但在 **LDV 场景下**，Master-Detail 会放大 **Account Skew** 问题——因为子记录**强制继承**父记录的 sharing，一个 Account 下挂太多 Master-Detail 子记录会直接触发 sharing recalculation 风暴。LDV 场景下**反而推荐用 Lookup + 自己写 Apex Trigger 维护汇总**，避开 Salesforce 的自动 sharing recalculation。考试会出场景题："某 Org 需要在 Account 下挂 5 万条 Contact 记录……"——答案不是 Master-Detail，而是 Lookup + 优化 sharing 策略。这个点反直觉，一定要记住。

**Bulk API 2.0 vs Bulk API 1.0 以为只是版本号升级** — Bulk API 2.0 是 2018 年后推出的新版本，**默认推荐用 2.0**。两者的关键差异：**Bulk API 2.0** 不需要自己创建和管理 batch（你只要上传 job，Salesforce 自动 chunk 和并发）、最大单 job 150 MB、支持 CSV、API 更简单、错误处理更清晰。**Bulk API 1.0** 需要自己创建 job、自己切 batch（每个 batch 最多 10,000 行）、支持 **PK Chunking**（把查询按主键切成小块）、支持 XML + CSV、能精细控制并发。**关键考点**：当数据量超过 **1000 万行**需要用 PK Chunking 优化查询时，**必须用 Bulk API 1.0**（2.0 不支持 PK Chunking）。Data Loader 底层默认走 Bulk API 2.0，但大 Org 迁移时通常切到 Informatica Cloud 或自己写 Bulk API 1.0 脚本。

**Defer Sharing Calculation 的使用场景不知道** — 当你需要**批量更新大量记录**（比如迁移 500 万条数据、或者 Role Hierarchy 重组）时，Salesforce 会在每次 update 后重新计算 sharing，导致作业跑几十个小时。**Defer Sharing Calculation** 是 Salesforce 提供的一个机制：你先开 Case 让 Salesforce Support 打开这个 feature，然后在数据迁移前**暂停 sharing 计算**，等所有数据导入完成后再**手动触发一次全量 sharing recalculation**——能把迁移时间从几十小时压缩到几小时。考试会出场景题："数据迁移要导入 1000 万 Opportunity，怎么优化 sharing 性能……"——答案包含 Defer Sharing Calculation。这是 LDV 迁移的经典手段，必须知道。

**Duplicate Rules vs Matching Rules 的关系搞混** — **Matching Rule** 定义"什么叫两条记录重复"（比如 Email + Phone 一样就算重复），是一个匹配条件的定义。**Duplicate Rule** 定义"匹配到重复记录时做什么"（Block / Allow with Alert / Report），并且**引用一个或多个 Matching Rule** 作为判定依据。两者是"规则 + 策略"的关系，必须配对使用。考试高频考点：Salesforce 内置了 3 个标准 Matching Rule（Account / Contact / Lead），你可以直接用或者自己创建 Custom Matching Rule（最多 5 个 active）。MDM 相关题目几乎都会出一道 Duplicate Rule 配置题。