如何用Stored Procedure实现Cosmos DB跨分区文档Upsert？

首先得明确一个核心限制：Cosmos DB的存储过程（Stored Procedure）本身是分区绑定的——单个SP调用只能在指定的单个分区键范围内执行事务，这是服务端的设计约束，所以你没法用一个SP直接处理跨分区的文档Upsert。针对你的场景，我给你几个可行的解决思路：

思路1：客户端侧按分区键分组，逐个调用SP #

这是对你现有代码改动最小的方案：先把待处理的文档按分区键（也就是你的code字段）分组，然后对每个分组单独调用SP，并指定对应的分区键参数。这样每个SP调用都在单个分区内执行，既保留了SP的事务性，又能处理跨分区的批量操作。

.NET代码示例 #

// 按分区键（code）分组
var groupedEcerts = digitalEcerts.GroupBy(ecert => ecert.Code);
var taskList = new List<Task<int>>();

foreach (var group in groupedEcerts)
{
    var requestOptions = new RequestOptions 
    { 
        PartitionKey = new PartitionKey(group.Key) // 指定当前分组的分区键
    };
    
    // 对当前分区的文档调用SP
    var task = _docDbClient.ExecuteStoredProcedureAsync<int>(
        UriFactory.CreateStoredProcedureUri(_docDbDatabaseName, _docDbDigitalEcertsCollectionName, "UpsertDigitalMembershipEcertAssignments"),
        requestOptions,
        group.ToList());
    
    taskList.Add(task);
}

// 等待所有分区的Upsert操作完成
await Task.WhenAll(taskList);

优缺点 #

• ✅ 优点：复用现有SP的业务逻辑，每个分区内的Upsert操作保持事务原子性；无需修改SP代码。
• ❌ 缺点：会产生多次SP调用，存在一定网络开销；需要客户端处理分组和并发逻辑。

思路2：使用Cosmos DB SDK的批量Upsert功能 #

如果你不需要严格的分区内事务保证，直接用SDK的批量操作是更简洁的方案。新版.NET SDK（3.x及以上）支持原生批量操作，并且可以通过EnableUpsert参数实现Upsert逻辑，自动处理跨分区的文档。

.NET代码示例 #

// 假设你使用的是新版Container客户端
var container = _docDbClient.GetContainer(_docDbDatabaseName, _docDbDigitalEcertsCollectionName);
var taskList = new List<Task>();

foreach (var ecert in digitalEcerts)
{
    var itemOptions = new ItemRequestOptions 
    { 
        EnableUpsert = true, // 开启Upsert模式：存在则更新，不存在则插入
        PartitionKey = new PartitionKey(ecert.Code)
    };
    
    var task = container.CreateItemAsync(ecert, null, itemOptions);
    taskList.Add(task);
}

await Task.WhenAll(taskList);

优缺点 #

• ✅ 优点：无需编写SP，代码更简洁；SDK内部优化了请求批量处理，性能较好；自动支持跨分区操作。
• ❌ 缺点：单个文档的Upsert是独立操作，没有分区内的事务原子性；如果需要复杂的前置查询判断（比如你的SP里先查再更新的逻辑），需要额外处理。

思路3：异步处理——Change Feed + Azure Function（适合高吞吐量场景） #

如果你的业务允许异步处理，可以把待Upsert的文档先写入一个临时集合，然后利用Cosmos DB的Change Feed触发Azure Function，在Function中对每个文档执行Upsert到目标集合。这种方案适合高并发、高吞吐量的场景，解耦了业务逻辑。

核心流程 #

1. 将所有待Upsert的文档写入一个临时的"待处理"集合。
2. 配置Azure Function监听该临时集合的Change Feed。
3. Function收到文档变更事件后，对目标集合执行单个文档的Upsert操作（自动处理分区键）。

优缺点 #

• ✅ 优点：异步解耦，适合高吞吐量场景；无需手动处理分组和并发；Function自动弹性扩缩容。
• ❌ 缺点：存在异步延迟，不适合实时性要求极高的场景；需要额外部署Azure Function资源。

对你现有SP的补充说明 #

你之前的SP代码本身是没问题的，但调用时必须指定分区键——因为SP的执行范围被限制在单个分区内。即使你在SP的queryDocuments中指定了partitionKey，SP的整体执行上下文还是需要绑定到某个分区，所以不指定PartitionKey调用时才会报错。

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