技能介绍

要解决什么问题

在 Azure 上存结构化、可查询的 NoSQL 数据时，Table Storage 与 Cosmos DB Table API 都依赖 PartitionKey + RowKey 的实体模型，而不是关系型表或文档库那一套 API。Python 侧若仍用连接字符串、混用同步/异步客户端，或跨分区扫全表，很容易在鉴权审计、资源释放和账单上踩坑。

技能如何组织内容

本技能围绕 azure.data.tables 说明两类客户端：TableServiceClient 负责建表/删表/列表；TableClient 负责实体的创建、读取、更新、删除与查询。文档强调用 DefaultAzureCredential 在本地与 Azure 托管环境间复用同一套鉴权，并用 with / async with 包裹客户端（异步场景还包括 azure.identity.aio 的凭据上下文），避免连接串绕过 Entra 轮换。

实体操作部分按常见路径展开：分区键设计、分区内查询、OData 风格过滤与属性投影、批量写入，以及 Python 类型与 Table 存储类型（如 datetime→DateTime、UUID→Guid）的对应关系。高吞吐场景指向异步客户端；幂等写入建议 upsert_entity，查询则强调参数化以防注入。

适用边界与注意点

Table 实体单条上限 1MB，查询成本与分区布局强相关——应优先按访问模式设计分区键，并在分区内完成批量与过滤。技能中的参考文件（如 capabilities、non-hero 场景）补充非核心能力与生产检查项；核心路径仍是键值实体 CRUD 与分区友好查询，不适合当作通用 OLTP 或复杂联表分析的主存储。

截图预览

使用场景

在 Azure 上写 Python 服务，需用托管标识读写 Storage Tables 实体，并避免把连接字符串写进配置或代码仓库。
多租户或设备类数据要按 PartitionKey 分桶，在分区内做带过滤条件的实体查询与同一分区内的批量 upsert。
从 TableServiceClient 创建或列出表后，用 TableClient 完成单实体 CRUD，并用参数化 OData 过滤查询特定属性。
写入 QPS 较高时选用 `azure.data.tables.aio` 异步客户端，配合 `async with` 管理客户端与 DefaultAzureCredential。