排除流中的 Apex_CPU_TIME_LIMIT_EXCEEDED 错误
当事务消耗过多 CPU 时间时，Salesforce 会抛出 Apex_CPU_TIME_LIMIT_EXCEEDED 错误。流与同一事务中的所有其他自动化共享此限制，包括 Apex 触发器。
所需的 Edition
| 查看支持的版本。 |
| 所需用户权限 | |
|---|---|
| 要使用 Flow Builder 中提供的所有流类型、元素和功能（包括 Einstein 和 Agentforce for Flow）打开、编辑、创建、激活或取消激活流： | 管理流 |
| 查看设置并访问调试日志： | 查看设置和配置 |
| 查看、保留和删除调试日志，并设置跟踪标记： | 查看所有数据 |
Salesforce 对每个同步事务强制实施 10,000 毫秒（10 秒）的单个 CPU 时间限制。该事务中的每个自动化部分，例如 Apex 触发器、流、工作流规则和流程，都来自相同的预算。如果其他自动化首先消耗大部分预算，即使优化的流也会失败。执行顺序取决于流类型。有关完整订单，请查看触发器和执行顺序。
- 保存前流的运行顺序早于保存后流。
- Apex 触发器根据触发器类型在流之前或之后运行。
对达到 CPU 时间限制的流进行故障排除和优化：
- 了解导致 CPU 限制错误的常见模式
- 确定哪些元素消耗最多的 CPU 时间
- 应用优化技术降低 CPU 消耗
- 实施预防指南，避免 CPU 限制错误
- CPU 限制错误的问题、解决方案和预防技术
确定常见的 CPU 限制问题，应用解决方案，并遵循预防技术，以避免 Apex_CPU_TIME_LIMIT_EXCEED 错误。 - 识别流中的 CPU 密集型元素
使用 Apex 调试日志精确定位流中消耗 CPU 时间最多的元素。
CPU 限制错误的问题、解决方案和预防技术
确定常见的 CPU 限制问题，应用解决方案，并遵循预防技术，以避免 Apex_CPU_TIME_LIMIT_EXCEED 错误。
此表为排除 CPU 限制错误提供了参考。每行描述一个常见问题、修复它的解决方案以及在未来流中防止它的技术。首先确定这些问题是否适用于您的流。如果没有应用，同一事务中的另一个自动化（例如 Apex 触发器、另一个流或工作流规则）会从相同的 CPU 预算中提取，这可能是罪魁祸首。要确定整个事务中消耗 CPU 的内容，请查看 Apex 调试日志。有关更多详细信息，请查看调试日志。
| 问题 | 解决方案 | 预防技术 |
|---|---|---|
循环内的数据操作语言 (DML) 操作 在循环路径中执行创建记录、更新记录或删除记录操作会消耗每次迭代的 CPU 时间。一次处理多个记录可以快速用尽限制。 示例：流循环 100 个业务机会，并在循环中使用创建记录元素为每个业务机会创建任务，从而产生 100 个单独的 DML 操作。 |
使用基于集合的数据操纵语言 (DML) 操作 在循环中，使用分配元素将记录添加到记录集合变量。循环完成后，使用单个创建记录、更新记录或删除记录元素一次处理整个集合。这种方法称为批量化。 示例：循环业务机会，使用分配元素为每个业务机会构建任务。然后，使用其他分配元素，将每个任务添加到集合变量。在循环后，使用创建记录元素一次创建所有任务。 有关详细信息，请参阅事务中流程批量化。 |
切勿将 DML 操作放在循环中。始终设计流，以在循环期间收集集合变量中的记录，然后在循环完成后执行 DML。 |
循环中的多个查询 在循环中获取记录元素会消耗大量 CPU 时间，特别是在查询大型对象或使用复杂筛选器时。 示例：流循环客户，并使用循环中的获取记录来获取每个客户的相关联系人，从而为每个客户生成一个查询。 |
循环前查询数据 在循环前，使用单个获取记录元素，并使用获取相关记录功能，通过适当的筛选器获取所有必要数据。在循环期间，使用收集的数据，而不是在每次迭代时查询。如果您无法使用单个“获取记录”元素，请使用“获取记录”元素获取主要记录。然后，使用其他“获取记录”元素获取次要记录。使用记录字段、In 运算符和第一个“获取记录”集合筛选次要记录。例如，客户 ID > 在 > 从获取客户获取客户。 示例：首先，使用“获取记录”元素获取所有相关联系人，该元素按客户 ID 筛选，然后在循环期间引用联系人集合。 |
避免循环中的查询。在进入循环之前，获取所有必要数据。 |
循环中的复杂公式 在每个循环迭代上运行复杂公式计算的分配元素会累积 CPU 时间，特别是字符串操作、日期计算或嵌套函数。 示例：流循环 500 个记录，每个迭代执行多个公式计算，以导出字段值。 |
简化公式 将复杂公式分解为更简单的步骤。计算在循环之外未更改的值。尽可能避免嵌套函数。考虑在对象上使用公式字段，而不是流公式。 对于整个集合的操作（例如筛选、映射或排序），转换元素比循环执行效率更高。要在单个查询中获取所有相关记录，而不是每个循环迭代一个查询，请使用带有 IN 运算符的获取记录元素。 有关更多信息，请查看转换元素。 |
简化公式，并将不会更改的计算移到循环之外。使用实际数据量测试公式性能。 |
处理大型记录集合 即使在适当的批量化情况下，在一个事务中处理数千条记录的计划流或批处理操作也会消耗太多的 CPU 时间。 示例：计划流会获取 5000 个客户记录，并在更新前对每个记录的数据执行复杂转换。 |
使用替代方法 对于大数据量，请考虑：
|
尽早筛选数据，以减少处理的记录数量。使用获取记录筛选器，以仅获取您需要的记录。在部署到生产环境之前，使用实际数据量进行测试。 |
事务中的多个流 当一个流触发其他流（通过记录更改或子流）时，事务中所有流的累积 CPU 时间计入限制。 示例：客户更新中的记录触发的流运行多个子流，也会触发相关对象上的其他记录触发的流。 |
减少流链 将相关自动化整合到更少的流中。查看流触发条件，以确保流仅在必要时运行。考虑使用条目条件来限制记录触发的流何时运行。 |
查看可在同一事务中运行的所有自动化（流、流程、工作流、触发器）的累积影响。监控和优化整个自动化链。 |
批量数据加载 在批量数据导入或批量更新期间运行的记录触发的流需要高效地处理所有记录。低效流在批量操作期间达到 CPU 限制，即使它们对于单个记录工作正常。 示例：用户导入 200 个客户记录。保存前记录触发的流会为每个客户执行多次查找和计算。 |
优化批量操作
有关更多信息，请查看转换元素。 |
始终假设记录触发的流同时处理多个记录。在部署到生产之前，使用批量数据加载进行测试（通过使用 Data Loader 或批量更新）。如果设计不当，完全适合单个记录的流可能会在批量操作期间失败。 |
一般预防指南
- 监控流性能：定期查看 Apex 调试日志，以识别接近 CPU 限制的流，即使它们尚未失败。定期监控有助于您在流导致生产问题之前对其进行优化。
- 使用现实数据进行测试：使用实际数据量测试流，以在激活前发现性能问题。调试模式通常使用一个记录进行测试，这不会显示批量操作问题。
- 文档优化决策：使用元素描述来记录您在何处应用了批量化或其他优化。本文档帮助未来的维护人员理解设计，并防止意外引入性能问题。
- 从简单开始并优化：以较小的增量构建流，在每个步骤测试性能。优化工作流比修复复杂的故障工作流更容易。
识别流中的 CPU 密集型元素
使用 Apex 调试日志精确定位流中消耗 CPU 时间最多的元素。
- 转到设置，并在快速查找框中输入调试日志。
- 为遇到错误的用户设置调试日志记录，或在调试模式下运行流。
- 通过运行流来重现错误。
- 打开生成的调试日志。
-
在调试日志中搜索这些关键事件。
FLOW_CREATE_INTERVIEW_BEGIN- 显示每个流何时开始FLOW_ELEMENT_LIMIT_USAGE- 显示每个流元素的 CPU 时间消耗CUMULATIVE_LIMIT_USAGE- 显示 CPU 运行总时间
-
识别 CPU 时间值高的元素。
常见罪魁祸首包括：
- 具有大集合的循环元素。
- 获取具有复杂筛选器的记录元素。
- 具有多个记录的 DML 操作（创建记录、更新记录、删除记录）。
- 具有复杂公式的分配元素。
您现在知道哪些元素消耗的 CPU 时间最多。使用此信息应用有针对性的优化。
有关调试日志的更多信息，请查看在开发人员控制台中使用日志。
