Azure Cosmos DB中DISTINCT关键字异常及请求率过高问题

我来帮你一步步解决这两个Cosmos DB的问题：

问题1：SDK执行DISTINCT查询时抛出请求速率过大错误 #

这个报错是Cosmos DB的典型RU（请求单位）不足问题。DISTINCT查询需要扫描全分区数据、执行去重计算，比普通count查询消耗更多的RU资源。当你的请求速率超过了容器配置的RU上限时，就会触发限流提示。

解决办法：

• 调整SDK重试策略：主流Cosmos DB SDK都内置了重试机制，你可以增加重试次数并设置指数退避间隔，让SDK自动在限流时重试请求。比如在.NET SDK里，可通过CosmosClientOptions配置RetryOptions；Java SDK里调整RetryPolicy参数。
• 临时提升容器RU配额：如果是一次性的大数据量查询，可以暂时调高容器的RU值，查询完成后再降回原配置，避免长期成本增加。
• 优化查询效率：确认fname字段在容器索引策略中被包含（默认自动索引所有字段，但如果手动修改过策略，要检查是否遗漏）。你已经用partition_key='employee'做过滤，这很好，确保查询只扫描目标分区，减少不必要的RU消耗。

问题2：DISTINCT查询计数与普通count结果一致，不符合预期 #

你的查询写法看似没问题，但结果不符合预期，可从以下几个方向排查：

1. 先验证子查询的实际结果
   单独执行子查询：

   SELECT distinct c.fname from c where c.partition_key='employee'
   

   查看返回的文档数量是否为256。如果还是17001，说明DISTINCT未生效：

   • 检查fname字段是否存在空值、空格或大小写差异（比如"Alice"和"alice"会被视为不同值，若你预期忽略大小写需额外处理）；
   • 确认容器索引策略未排除fname字段——无索引支持的话，DISTINCT无法正确完成去重。

2. 尝试更简洁的COUNT(DISTINCT)语法
   Cosmos DB支持直接使用COUNT(DISTINCT)，试试这个写法：

   SELECT value count(DISTINCT c.fname) from c where c.partition_key='employee'
   

   这种写法更直接，能避免子查询可能带来的潜在执行逻辑问题，看看结果是否符合预期。

3. 用GROUP BY验证数据一致性
   执行分组查询确认每个fname的出现次数，统计结果行数就是不同fname的数量：

   SELECT c.fname, count(1) as occurrence from c where c.partition_key='employee' GROUP BY c.fname
   

   把结果行数和你预期的256对比，确认数据本身是否和你的认知一致。

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