Dynamics CRM并行执行请求：如何结合ExecuteTransactionRequest优化Dataverse操作速度

关于并行与ExecuteTransactionRequest的兼容性 #

• 二者无法直接结合使用，ExecuteTransactionRequest的设计逻辑是将所有操作封装为单原子事务，提交到Dataverse后端后会串行执行所有请求，确保所有操作要么全部成功要么全部回滚。在客户端侧并行构造请求不会提升执行速度，反而可能增加额外的线程调度开销。

性能优化方案 #

场景1：必须保留全局事务原子性（400条操作必须同成败） #

• 优化请求包大小：剔除操作中不需要的字段，更新操作仅传递需修改的字段、不要全字段提交，减少序列化与传输开销
• 调整SDK配置：使用最新版Dataverse SDK，设置EnableAffinityCookie = false，同时将请求的MaxConnections参数调整为10~20，适配Azure Function的出站连接限制
• 下沉前置校验逻辑：将当前在Azure Function中逐行执行的校验逻辑改为批量处理，提前拉取Dataverse对照数据一次性完成批量匹配，避免每条记录都单独发起Dataverse查询做条件校验，这部分是大部分场景下的核心耗时点
• 升级Azure Function托管计划：如果当前使用消费计划，更换为弹性Premium计划，消除冷启动开销同时提升CPU/内存性能，加快本地校验与请求构造速度
  以上优化完成后通常可将耗时压缩到5~8秒区间。

场景2：可放弃全局原子性，允许按批次保证原子性或接受部分失败 #

• 拆分事务批次：将400条记录拆分为4_{8个批次，每批次50}100条，每个批次单独用ExecuteTransactionRequest封装，客户端并行提交多个批次请求，Dataverse后端可并行处理多个独立事务，无数据冲突的前提下耗时可降到2~3秒
• 替换为ExecuteMultipleRequest：如果不需要批次内严格原子性，可改用ExecuteMultipleRequest并设置ContinueOnError = true，并行提交多个请求包，吞吐量比拆分ExecuteTransactionRequest更高
• 注意事项：如果记录间存在关联依赖（如某条记录的更新依赖另一条的新增结果），拆分批次时需将有依赖的记录归入同一批次，避免并行执行出现关联错误

内容的提问来源于stack exchange，提问作者MVC_Nhibernate