Azure Cosmos DB默认索引策略无法适配StartsWith()函数的问题咨询

Let's unpack your two questions clearly—Cosmos DB's indexing rules can feel tricky even after digging through the docs, so I’ll break this down in plain terms!

1. Why didn't the default indexing strategy work? #

The default strategy uses "path": "/*" which does index all top-level properties in your documents—but here’s the critical catch: for string fields, it only creates a Hash index, not a Range index.

Hash indexes are perfect for equality checks (like WHERE c.name = 'Bob'), but they can’t support prefix-matching operations like STARTSWITH(). When you ran your query, Cosmos DB realized it couldn’t use the existing Hash index to efficiently find matches, so it threw that error about needing a range-indexed path (or allowing a full scan, which is inefficient for large datasets).

2. Why did you need to add "path": "/"? #

First, let’s clarify the key difference between "/*" and "/":

• "/*" targets all direct child properties at the root of your documents (e.g., /name, /age), but doesn’t recursively index nested fields (like /address/city).
• "path": "/" indexes the entire document recursively—meaning every property (top-level and nested) gets indexed according to the rules you define for this path.

In your modified strategy, the "path": "/" entry acts as a fallback: it ensures all numeric fields get a Range index (great for range queries like WHERE c.age > 30) and all other string fields keep a Hash index (for equality checks).

That said, the actual fix for your STARTSWITH issue is the "path": "/name/?" entry, which explicitly adds a Range index for the name string field. You might have thought "path": "/" was mandatory because if you removed it entirely, you’d lose indexing for all fields except name—which would break other queries against your container. Adding "path": "/" preserves the default indexing behavior for all other fields while adding the specific Range index you need for name.

内容的提问来源于stack exchange，提问作者Mr. 14