Salesforce 数据倾斜：成因、影响与性能优化深度解析

八月 31, 2025

背景与应用场景

在 Salesforce 的多租户 (multi-tenant) 架构中，所有客户共享底层的硬件、应用服务器和数据库资源。为了保证平台的公平性和稳定性，Salesforce 制定了一系列的限制，即所谓的 Governor Limits。然而，除了这些明确的限制外，还有一个更为隐蔽的性能杀手，它不直接触发错误，却能显著拖慢系统响应、导致用户体验下降，甚至引发严重的系统问题——这就是 Data Skew (数据倾斜)。

Data Skew 指的是在 Salesforce 组织中，数据分布极不均衡的一种状态。简单来说，就是少量记录承载了远超平均水平的数据量。这种情况在拥有大量数据 (Large Data Volumes, LDV) 的企业级 Salesforce 实施中尤为常见。一个典型的场景是：

客户数据倾斜 (Account Skew): 一个客户 (Account) 记录下关联了数百万个联系人 (Contact)、业务机会 (Opportunity) 或案例 (Case)。例如，一个“未分配客户”或“合作伙伴总客户”的记录，成为了大量子记录的父级。
所有权倾斜 (Ownership Skew): 一个用户 (User) 或队列 (Queue) 拥有了某个对象（如 Lead 或 Case）的绝大部分记录。这通常发生在数据集成或数据迁移场景中，所有记录都被分配给了同一个“集成用户”。
查找倾斜 (Lookup Skew): 大量的记录通过查找关系 (Lookup Relationship) 指向了同一个父记录。这本质上是客户数据倾斜的一种泛化形式，任何对象都可能成为这个“倾斜”的父记录。

当 Data Skew 发生时，会直接影响平台的性能和稳定性。例如，当用户尝试更新一个拥有百万子记录的客户时，系统为了维护数据完整性可能会锁定大量相关记录，导致其他用户或自动化流程在访问这些记录时出现长时间等待甚至超时，并抛出 UNABLE_TO_LOCK_ROW 的错误。同样，当一个拥有海量记录的用户在角色层级 (Role Hierarchy) 中发生变动时，系统需要重新计算共享规则 (Sharing Rules)，这个过程可能会持续数小时甚至数天，严重影响业务的正常运转。作为 Salesforce 技术架构师，识别、预防和解决 Data Skew 是保障系统健康和可扩展性的核心职责之一。

原理说明

要理解 Data Skew 为何会成为一个严重问题，我们需要深入了解 Salesforce 的底层机制，特别是数据存储、记录锁定 (Record Locking) 和共享计算 (Sharing Calculation)。

记录锁定 (Record Locking)

Salesforce 数据库在执行数据操作语言 (DML) 操作（如 insert, update, delete）时，为了保证数据的一致性和完整性，会自动为正在被修改的记录加上锁。这个锁可以防止其他事务 (transaction) 同时修改同一条记录。对于父子关系（Master-Detail 或 Lookup），当子记录被修改时，Salesforce 可能会对父记录加上一个共享锁（Share Lock）。更关键的是，当父记录被更新时，Salesforce 为了维护汇总字段 (Roll-Up Summary Fields) 或其他内部关系，可能会锁定其所有的子记录。

这就是 Lookup Skew 和 Account Skew 问题的核心。想象一下，一个 Account 拥有 100,000 个 Contact 记录。当一个用户或自动化流程更新这个 Account 时，数据库可能会尝试锁定这 100,000 个 Contact。如果此时有其他用户或并发的后台进程正试图更新其中的任何一个 Contact，就会发生锁竞争 (Lock Contention)。当等待锁释放的请求过多或时间过长，系统就会抛出 UNABLE_TO_LOCK_ROW 错误，导致事务回滚。这种问题在高并发的集成场景中尤为突出。

共享计算 (Sharing Calculation)

共享计算是 Salesforce 根据角色层级、共享规则、团队成员等设置来决定用户对记录访问权限的后台过程。当一个用户的角色发生变化，或者一个共享规则被修改时，系统会触发一次或多次共享计算任务。对于 Ownership Skew，问题就出在这里。

假设一个集成用户拥有 500,000 个 Case 记录，并且这个用户位于一个复杂的角色层级中。如果这个用户被移动到另一个角色，Salesforce 必须重新计算这 500,000 个 Case 及其关联记录的共享表 (Share Table)。这个计算量是巨大的，因为它不仅涉及到该用户，还涉及到层级中所有上级用户的访问权限。这个过程会消耗大量的后台处理资源，并且可能导致共享规则的更新出现严重延迟，使得用户在一段时间内无法访问他们本应有权限访问的数据。

查询性能 (Query Performance)

Data Skew 同样会影响 SOQL 查询、报表 (Reports) 和列表视图 (List Views) 的性能。Salesforce 的查询优化器 (Query Optimizer) 在处理大数据量时非常高效，但前提是查询条件是“可选择性的” (selective)，即能够有效利用索引 (Index) 来缩小查询范围。当查询条件涉及到倾斜数据时，比如 SELECT Id FROM Contact WHERE AccountId = ' skewed_account_id '，即使 `AccountId` 是索引字段，查询优化器也可能因为需要返回的记录数过多而选择全表扫描 (Full Table Scan) 而不是使用索引，导致查询性能急剧下降。

示例代码

Data Skew 本身是一个数据架构问题，而不是一个纯粹的代码问题。因此，代码的主要作用在于检测潜在的数据倾斜，而不是直接“修复”它。作为架构师，第一步就是识别出组织中哪些地方存在倾斜。以下是一些用于检测常见数据倾斜类型的 SOQL 查询示例。

检测客户倾斜 (Account Skew)

这条查询可以找出拥有最多关联联系人 (Contact) 的前 10 个客户。通过定期运行此类查询，您可以主动监控并识别出潜在的倾斜热点。

// 此 SOQL 查询用于识别在 Contact 对象上存在数据倾斜的父级 Account。
// 它通过聚合函数 COUNT(Id) 计算每个 AccountId 关联的 Contact 记录数量。
SELECT 
    AccountId, 
    COUNT(Id) contactCount // 使用 COUNT(Id) 对每个分组中的记录进行计数，并为其指定别名 contactCount。
FROM 
    Contact 
WHERE 
    AccountId != NULL // 过滤掉没有关联 Account 的 Contact 记录。
GROUP BY 
    AccountId // 按 AccountId 对 Contact 记录进行分组，这是执行聚合计算的前提。
ORDER BY 
    COUNT(Id) DESC // 按每个分组的记录数（即 Contact 数量）进行降序排序，将拥有最多 Contact 的 Account 排在最前面。
LIMIT 10 // 仅返回排序后的前 10 条结果，帮助我们聚焦于最严重的倾斜点。

分析结果： 如果查询结果显示某个 Account 拥有远超其他客户的 Contact 数量（例如，成千上万甚至更多），那么这个 Account 就是一个倾斜点。

检测所有权倾斜 (Ownership Skew)

这条查询可以找出在某个特定对象（以 Case 为例）上拥有最多记录的前 10 个所有者 (User 或 Queue)。

// 此 SOQL 查询用于识别在 Case 对象上拥有记录最多的所有者（用户或队列）。
// 这对于发现由于集成、数据加载或不合理的分配规则导致的 Ownership Skew 至关重要。
SELECT 
    OwnerId, 
    COUNT(Id) caseCount // 使用 COUNT(Id) 计算每个 OwnerId 拥有的 Case 记录数量。
FROM 
    Case 
GROUP BY 
    OwnerId // 按 OwnerId 进行分组。
ORDER BY 
    COUNT(Id) DESC // 按拥有的 Case 数量进行降序排序。
LIMIT 10 // 限制结果为前 10 个最主要的所有者。

分析结果： 如果某个用户（特别是集成用户）或某个通用队列拥有了绝大多数记录，这就构成了所有权倾斜。您需要进一步查询 `User` 或 `Group` (Queue 的 SObject 类型) 对象，以确定 `OwnerId` 对应的具体名称。

注意事项

在处理 Data Skew 问题时，需要考虑以下几个关键点：

权限 (Permissions): 运行上述检测查询的用户需要对相关对象（如 Contact, Case）拥有“读取”权限。
API 限制与性能 (API Limits & Performance): 在数据量巨大的对象上执行 `GROUP BY` 查询可能会非常耗时，甚至可能超出 SOQL 查询的超时限制。建议在非工作时间执行这些查询，或者使用异步方式（如 Batch Apex）来处理。对于非常大的数据集，可以考虑使用 Salesforce 的 Bulk API 或 Tableau CRM (原 Einstein Analytics) 进行更深入的分析。
错误处理 (Error Handling): 在编码层面，如果您的业务逻辑需要与可能存在倾斜的记录进行交互，必须做好充分的错误处理。特别是要捕获并优雅地处理 `System.DmlException` 中常见的 `UNABLE_TO_LOCK_ROW` 错误。简单的重试机制可能无法解决问题，因为锁竞争可能持续存在。更有效的策略是：
- 减少事务的范围和批量大小 (batch size)。
- 将对倾斜父记录的更新操作进行序列化处理，例如通过一个专门的 Queueable 任务链来保证同一时间只有一个事务在更新该记录。
- 在用户界面层面，提供明确的反馈，告知用户操作正在后台处理中，避免用户反复提交。
数据模型的重要性 (Data Model Impact): 解决 Data Skew 的根本方法往往在于优化数据模型和业务流程，而不是仅仅依靠代码层面的规避。

总结与最佳实践

Data Skew 是一个复杂且影响深远的性能问题，它源于 Salesforce 多租户架构的内在特性。作为技术架构师，我们的目标应该是通过优秀的设计来预防倾斜，通过主动的监控来发现倾斜，并通过合理的策略来缓解其影响。

以下是一些应对 Data Skew 的最佳实践：

避免使用“垃圾桶”式的记录
在设计数据模型时，坚决避免创建通用的、用于挂载孤儿记录的父记录，例如“未分配客户”或“默认部门”。应设计流程确保每条子记录都能关联到具体的、有业务意义的父记录上。
合理分配记录所有权
对于集成和数据迁移，不要将所有记录都分配给单一的集成用户。可以根据记录的区域、类型或其他属性，将其分配给不同的用户、公共组 (Public Groups) 或队列。这有助于分散所有权，减轻共享计算的压力。
优化角色层级
避免将拥有大量记录的用户（如高级经理或系统管理员）置于角色层级的顶端。如果业务需要，可以考虑创建一个扁平的角色分支，专门用于管理这些“重负载”用户，以减少共享计算的传播范围。
引入数据分层或归档策略
对于拥有大量子记录的父对象，考虑实施数据归档策略。将不再活跃的旧记录（如已关闭多年的 Case）移动到外部存储系统或 Salesforce 的自定义大对象 (BigObjects) 中，以减少父记录上的子记录数量。
使用异步处理
对于需要更新倾斜记录的后台操作，优先使用异步 Apex，如 Queueable 或 Batch Apex。这不仅可以避免对用户界面的阻塞，还能更好地控制事务边界和错误处理，例如实现对锁竞争的有序重试或序列化执行。
与 Salesforce 支持合作
在极端情况下，如果共享计算的性能问题非常严重，可以联系 Salesforce 支持。他们拥有一些后台工具，例如可以暂时挂起（defer）共享计算，以便您完成大规模的组织结构或数据所有权变更，之后再统一恢复计算。

总之，应对 Data Skew 需要一种全局视角，它结合了数据架构、业务流程分析和技术实现。通过在项目早期就建立起对 Data Skew 的认知并遵循最佳实践，我们可以构建出更健壮、更具可扩展性的 Salesforce 应用。

Salesforce中文网