重新设计流
有时最好重新访问流，确定能否修改其设计来提高整体性能。 本重新评估还允许您应用流最初实施时不可用的新功能或增强功能。
Copilot 如何提供帮助？
随着 Copilot 的出现，您还可以使用 Copilot 体验来帮助识别 Flow 问题。 例如：
通过解释流的结构和用途，要求 Copilot 审查您的流；或提供详细信息，例如涉及哪些触发器、操作和循环。
您可以提示 Copilot 识别潜在的效率低下问题，例如可能导致延迟的循环或条件。 提出如下问题：
“此流中是否存在任何效率低下的循环？”
“您是否可以找到流速度可能缓慢的位置？”
在优化 方面，您还可以要求 Copilot 提供优化建议。 要审查的常见区域包括：
触发器：建议使用筛选器以避免不必要的触发器。
循环：检查您是否有效地使用“应用到每一个”，并确保循环没有处理不必要的项目。
条件：识别可以简化条件的位置。
询问 Copilot 如下问题：
“您是否可以优化我的条件？”
“我是否可以使用其他操作来加快此流？”
它甚至可以帮助进行错误处理和调试。 您可以使用 Copilot 识别流中的潜在故障点。 向 Copilot 寻求有关分析运行历史记录和错误消息的帮助：
“哪些错误导致此流失败？”
“您是否可以检查特定运行的错误日志？”
这些提示和其他提示可以帮助您识别问题、改进性能以及了解流运行缓慢的原因。 但是，在完成流程时仔细观察也有很大帮助。
使用 OData 筛选器查询限制返回的条目
SharePoint 连接器基于 REST API 生成，因此支持使用 OData 筛选服务器端数据。 使用 OData 的优势包括减少引入流中的数据量以及减少循环记录集查找感兴趣的记录的需要。
考虑包含超过 100 项计算机设备信息的 Microsoft Lists 列表。 列表包含列出所有制造商的制造商名称列。 本列和 OData 的可用性允许您在服务器端的制造商级别进行筛选，缩短流运行所需总时间。
在 SharePoint 获取项目操作中，在筛选器查询字段中添加公式筛选 Microsoft 设备。
现在，运行流时，仅 Microsoft 设备可见。
修改 Do until 条件
Do until步骤执行操作直到某个条件为 true。
更改Do until条件限制有助于加快流的运行速度。 默认设置为计数 60，即每小时运行。 基本上，流将每小时检查 60 次，以确定是否已满足条件。 最长持续时间计数为 30 天，计数为 5,000。
可以采取的性能改进方法包括：
将PT1H改为PT24H（24 小时）或改为PT72H（72 小时）。
减少计数，减少循环总数。
如在Do until条件中添加获取项目等查询类型操作，则添加筛选器查询。
保持选中配置运行条件字段中的成功复选框。 如果上个步骤失败，您不希望运行本步骤。
避免嵌套操作。
减少计划流的频率
Power Automate 允许创建基于开始时间触发流的计划云端流。
您可以灵活地每秒运行流，但运行流通常会耗尽 API 请求限制。
所有 Microsoft Power Platform 用户均根据为其分配的许可证获得有限的请求次数。 下表定义用户可在 24 小时内提出的请求数。
| 用户许可证 | 每 24 小时 API 请求数 |
|---|---|
| Power Apps 每用户计划 | 5000 |
| Power Automate 每用户计划 | 5000 |
| Microsoft 365 许可证 | 2000 |
| Power Apps 每应用计划 | 每个应用通行证 1,000 |