在Cosmos DB中更新数百条文档：选存储过程还是批量更新？

结论先行 #

针对你的需求——数百条文档更新、无需事务、允许部分失败且需记录失败情况、追求低成本——客户端批量更新是更合适的选择。下面详细拆解两种方案的差异：

存储过程的实际问题 #

存储过程看似是服务器端批量操作的首选，但结合你的需求来看有几个硬伤：

• 预收费浪费：正如你看到的文档说明，存储过程执行前会预扣RU，哪怕实际执行消耗的RU远低于预估值，也不会退还差额。对于数百条文档的小批量操作，这种预收费很容易造成不必要的成本支出。
• 调试与维护麻烦：存储过程用JavaScript编写，调试依赖Cosmos DB的工具，远不如客户端代码（比如C#/Python）灵活。后续要修改更新逻辑，还得重新部署存储过程，流程繁琐。
• 失败追踪不直观：如果执行中部分文档更新失败，你得在存储过程里手动记录失败信息，后续排查还要去看服务器端的日志，不如客户端直接捕获异常来得清晰。

客户端批量更新的适配性 #

客户端批量更新刚好匹配你的需求：

• 成本精准可控：完全按实际消耗的RU计费，没有预收费的浪费。你还可以通过两个技巧进一步压低成本：
  • 控制批量大小：每次提交20-50条更新（根据你的文档大小调整，单批次RU尽量控制在几百以内）
  • 设置低优先级请求：把更新请求的优先级设为Low，Cosmos DB会给这类请求更低的计费费率，虽然延迟会增加几秒，但完全符合你的时间容忍度
• 失败记录清晰：每条更新请求失败时，客户端可以直接捕获异常，把失败的文档ID、错误原因存到本地日志或另一个集合里，后续重试或排查都很方便
• 灵活易改：更新逻辑写在客户端代码里，调试、修改都不用依赖Cosmos DB服务器，迭代效率高

实操建议 #

推荐用「分页查询+分批更新」的流程：

1. 先写带筛选条件的查询，用分页（比如每次取100条）拉取需要更新的文档，确保查询用到了索引（避免全表扫描浪费RU）
2. 把拉取到的文档分成小批次（20-50条/批），每批次提交更新请求
3. 对每个批次的请求做异常捕获，记录失败的文档信息

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