如何在Azure Cosmos DB中通过id而非_rid使用GET请求获取文档？

当然可以！你完全不需要依赖SQL查询或者_rid元数据，直接用自己生成的GUID类型id字段就能高效获取Cosmos DB文档，而且微软技术支持提到的「GET请求比SQL查询RU消耗低得多」确实是对的——点读操作（Direct Read）是Cosmos DB里最节省RU的读取方式之一。

使用azure.cosmos Python包实现 #

Python SDK提供了直接通过自定义id和分区键读取文档的方法，完全不需要SQL查询或_rid。核心用Container.read_item()方法，这就是官方推荐的高效点读操作：

from azure.cosmos import CosmosClient, exceptions

# 初始化Cosmos客户端
endpoint = "你的Cosmos DB账户端点"
account_key = "你的账户密钥"
client = CosmosClient(endpoint, account_key)

# 定位到目标数据库和容器
db_name = "你的数据库名称"
container_name = "你的容器名称"
database = client.get_database_client(db_name)
container = database.get_container_client(container_name)

# 目标文档的GUID id和对应的分区键值（必须和文档实际的分区键一致）
target_guid_id = "你要获取的文档GUID"
partition_key_val = "该文档对应的分区键值"

try:
    # 直接通过id+分区键读取文档
    target_item = container.read_item(item=target_guid_id, partition_key=partition_key_val)
    print("成功获取文档:", target_item)
except exceptions.CosmosResourceNotFoundError:
    print("未找到对应GUID的文档")

这个方法的RU消耗极低（通常1KB以内的文档仅消耗1个RU），远低于SQL查询的消耗，完全符合你想要的高效读取需求，而且全程不需要接触_rid元数据。

使用自定义REST API请求实现 #

如果你想自己构造HTTP请求，也可以直接通过REST端点实现点读，同样不需要SQL或_rid：

请求的端点格式为：

GET https://<你的Cosmos账户名>.documents.azure.com/dbs/<数据库ID>/colls/<容器ID>/docs/<你的GUID id>

必须包含以下关键请求头：

• Authorization: 符合Cosmos DB规则的授权令牌（用账户密钥生成，格式为type=master&ver=1.0&sig=生成的签名串）
• x-ms-documentdb-partition-key: 目标文档的分区键值，需用JSON格式包裹，比如"your-partition-value"
• x-ms-version: 指定API版本，比如2023-03-15
• x-ms-date: 请求的UTC时间

举个curl命令的示例（需替换占位符并生成合法的授权令牌）：

curl -X GET "https://your-account.documents.azure.com/dbs/your-db-id/colls/your-container-id/docs/your-guid-id" \
-H "Authorization: type=master&ver=1.0&sig=your-generated-signature" \
-H "x-ms-documentdb-partition-key: \"your-partition-value\"" \
-H "x-ms-version: 2023-03-15" \
-H "x-ms-date: Tue, 10 Oct 2023 12:00:00 GMT"

这个请求和Python SDK的read_item()底层逻辑完全一致，都是高效的点读操作，不会触发SQL查询，也不需要依赖_rid。

关键注意事项 #

• 必须确保传递的分区键值和文档实际的分区键完全匹配，否则会出现「资源未找到」或者触发跨分区查询（后者会大幅增加RU消耗）
• 你通过批量Upsert存储过程创建的文档，只要设置了自定义GUID类型的id字段，Cosmos DB会自动为这个字段建立索引，完全支持点读操作
• 对于1亿级别的文档量，这种点读方式的性能和RU优势会非常显著，每个请求响应速度极快且消耗极低

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