D365 C#批量检索与更新速度过慢问题排查求助

哇，每秒1-2条的更新速度确实太拖后腿了——数十万条记录的话得花好几天才能搞定，肯定是实现里有拖慢性能的细节没处理好。我之前做D365批量更新时也踩过类似的坑，给你列几个最常见的优化方向，应该能把速度拉到每秒几百条的水平：

1. 别再单条逐个更新了！用批量操作 #

这是最容易犯的错误：查一条、更一条，每次更新都单独调用UpdateRequest。D365的API每次请求都要走完整的HTTP往返，单条操作的开销全耗在网络和服务端初始化上了。

改用ExecuteMultipleRequest批量提交更新请求，一次可以打包200-500条（别超过1000条，避免超时），能把吞吐量提升几十倍。示例代码大概是这样：

// 复用全局的ServiceClient实例（别每次都新建）
var service = new ServiceClient(connectionString);

var batchRequest = new ExecuteMultipleRequest()
{
    Settings = new ExecuteMultipleSettings()
    {
        ContinueOnError = false,
        ReturnResponses = false // 不需要返回结果的话设为false，能更快
    },
    Requests = new OrganizationRequestCollection()
};

// 假设你已经分页拉取了一批待更新记录
foreach (var record in currentBatch)
{
    var updateReq = new UpdateRequest()
    {
        Target = new Entity("your_entity_name", record.Id)
        {
            ["target_field"] = updatedValue // 只更新需要修改的字段，别全量赋值
        }
    };
    batchRequest.Requests.Add(updateReq);

    // 每200条提交一次批量请求
    if (batchRequest.Requests.Count >= 200)
    {
        service.Execute(batchRequest);
        batchRequest.Requests.Clear();
    }
}

// 提交剩余的最后一批
if (batchRequest.Requests.Count > 0)
{
    service.Execute(batchRequest);
}

2. 优化FetchXML查询的效率 #

如果你的查询本身就慢，后续更新再快也没用：

• 别用*返回所有字段，只拉取更新需要用到的字段（比如主键+待更新字段）；
• 过滤条件尽量用有索引的字段（比如主字段、常用筛选字段），避免全表扫描；
• 分页查询！一次性拉几十万条记录不仅内存扛不住，查询本身也会超时。每次拉200-500条，处理完再取下一页。

3. 关闭不必要的插件/工作流 #

更新操作触发的插件、工作流会额外消耗服务端资源。如果是纯批量数据更新，业务上允许的话：

• 临时禁用非必要的插件（事后记得恢复）；
• 在请求里加上SuppressPluginExecution参数（注意：需要对应的权限，而且要确认不会影响核心业务逻辑）。

4. 复用ServiceClient实例 #

如果你的代码里每次更新都新建ServiceClient或OrganizationServiceProxy，那每次都要重新建立连接，这会浪费大量时间。全局复用一个服务实例，保持连接打开（多线程场景下注意线程安全，每个线程单独用一个实例）。

5. 避免无意义的重复操作 #

比如有些开发者会先查询记录，更新后又再次查询确认；或者明明字段值没变化，还是强行提交更新。确保只对真正需要修改的字段执行更新，不要做多余的校验或查询。

6. 谨慎使用多线程（可选） #

如果业务逻辑允许，可以用2-5个线程同时处理不同批次的记录，但要注意D365的并发限制——别开太多线程，不然容易触发限流。每个线程用单独的ServiceClient实例，各自提交批量请求。

先从批量更新和查询优化这两点入手，这是最常见的性能瓶颈，调整后应该能直接把速度拉到每秒几百条的级别。

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