Cosmos DB请求量远超预期（达100倍）排查咨询

可能的核心原因 #

1. Cosmos DB内部隐性请求的统计 #

Cosmos DB的TotalRequests指标会统计所有针对服务端的请求，包括用户看不到的内部操作：

• 一致性同步请求：BOUNDED_STALENESS级别下，后台需要跨副本同步数据以保证一致性，每个用户请求可能触发多份副本间的同步请求。即使切换到EVENTUAL减少了部分同步，但热分区的高频访问会让剩余的内部同步请求量依然被放大。
• SDK自动分页/预取：如果你的查询返回结果集较大，Cosmos DB SDK会自动分页获取数据，每次分页都会发起独立请求。应用端可能只统计了初始的查询调用，未计入后续的分页请求。
• 索引维护请求：热分区的高频读写会触发后台索引维护操作，这些系统级请求也会被计入TotalRequests。

2. 应用端指标统计的遗漏 #

• SDK自动重试：当遇到限流（429）或超时，SDK会自动发起重试请求，这些重试会被Cosmos DB计数，但应用端可能只统计了初始的调用次数，未包含重试。
• 底层元数据/心跳请求：SDK会定期发起元数据查询（比如获取分区信息）或心跳请求以维持连接，这些请求应用端通常不会统计，但会被计入TotalRequests。

3. 热分区的放大效应 #

你的容器存在严重热分区，所有请求集中在partitionKey=0的分区：

• Cosmos DB为了处理热分区负载，可能内部触发跨副本的调度或重试操作，这些额外动作会产生额外的请求计数。
• 热分区下容易出现请求排队，进一步触发SDK重试，形成请求数的连锁放大。

4. 查询与索引的匹配问题 #

虽然你创建了复合索引，需确认索引顺序是否完全匹配查询条件：

• 你的查询条件顺序是partitionKey = 0 and index1 = 1 and index2 = 2，复合索引需要以partitionKey作为首字段，依次是index1、index2，否则查询无法高效利用索引，可能触发内部的额外扫描操作，间接增加请求数。
• SELECT *会返回文档所有字段，若文档体积较大，SDK可能会分块返回数据，也会增加请求次数。

排查建议 #

• 拆分Cosmos DB的Request Charge指标，按操作类型（Query、系统操作等）查看占比，判断是否是内部系统请求拉高了计数。
• 开启应用端SDK的详细日志，统计所有实际发送到Cosmos DB的请求（包括重试、分页），和应用端现有指标做对比。
• 使用Cosmos DB查询性能分析工具查看查询执行计划，确认是否正确利用了复合索引。
• 优先解决热分区问题，通过重新设计分区键分散请求，从根源减少内部同步和重试的请求量。

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