表格存储的表为半结构化设计：创建数据表时只需指定 1～4 列主键列，属性列无需预先定义。每行数据可以拥有数量和类型各不相同的属性列，且单张表支持的属性列总数没有限制。
应用程序写入数据时，需要指定本次写入操作所有列（包括主键列和属性列）的列名和列值。
分区键的工作原理
主键的第一列即为分区键。当表的数据量达到阈值时，表格存储会根据分区键列值的范围自动对数据进行分区，以此实现读写负载均衡。
新创建的表默认拥有一个分区，存放该表的全部数据。随着表数据量的增长，表格存储会创建更多分区，每个分区负责存储分区键列值落在某一特定范围内的数据。分区切分遵循分区键数据类型（如 Integer、String）的自然排序顺序。
数据分区还会影响预留读/写吞吐量的使用。当表拥有多个分区时，预留读吞吐量和预留写吞吐量会按比例预分配到各个分区。
如何选择分区键
分区键决定数据如何在各分区间分布，直接影响大表场景下的读写性能。好的分区键能让访问均匀分散到各分区；差的分区键会把流量集中在某一分区，形成热点。
以下表格列出了常见的分区键候选方案及其适用性评估：
|
分区键候选 |
均匀性 |
说明 |
|
用户 ID（基数高、取值众多） |
好 |
访问自然分散到各分区 |
|
设备 ID（设备数量多、访问模式相近） |
好 |
访问分布均匀 |
|
时间戳（频繁查询最新数据的场景） |
差 |
最新时间戳集中写入，形成热点分区 |
|
状态码（取值范围很小） |
差 |
基数低，数据集中在少数分区 |
|
客户性别（Male、Female） |
差 |
取值固定且范围极小 |
选择分区键时，遵循以下原则：
避免使用取值固定或范围较小的属性，例如客户性别（Male、Female）。
避免使用按自然序排序后会出现明显访问热点的属性，例如在查询最新数据场景中使用时间戳。
优先选择基数高、访问分布均匀的属性，例如用户 ID。
更多信息，请参见表操作篇。
无法预估访问热点时如何处理
若无法提前判断哪些分区键值会成为访问热点，可以在写入时为分区键添加后缀，将写入流量分散到更多分区。根据查询模式的不同，有以下两种策略：
|
策略 |
适用场景 |
实现方式 |
代价 |
|
随机后缀 |
写入吞吐量是首要目标，较少按主键读取单条数据 |
在分区键值后拼接随机数（如 1～200），例如 |
写入流量分散，但读取单条数据时需查询所有后缀变体并合并结果。 |
|
计算后缀 |
需要按主键精确读取单条数据 |
将后缀由可在查询时重新计算的值推导而来，例如对 UserID 取哈希后取模： |
可以通过重新计算后缀来定位单条数据，但无法再对原始分区键执行范围读取操作（GetRange）。 |
两种策略都只需在写入时增加一次轻量级计算。
单账号表个数限制说明
每个表格存储账号最多可创建 10 个实例，每个实例最多可创建 64 个表，共计 640 个表。该限制源于表格存储的分布式架构：在特定集群规模下，表的数量是有界的资源属性。
触达该限制通常意味着以下两种设计模式，而表格存储的大表模型正是为此而设计：
高数据量场景：传统数据库（如 MySQL）通过分库分表解决海量数据问题，表格存储的分布式架构从根本上消除了这一需求——将结构化或半结构化数据存入一张稀疏大表，无需担心数据量增长带来的访问性能问题。
多租户应用场景：若为每个租户（如供应商、合作伙伴）单独创建一组表，账号表数量会迅速达到上限，且增加全局数据分析的难度。建议将租户标识作为主键的一部分，将同类数据统一存入一张大表。
如需提高账号下的表个数上限，请提交工单申请。
更多限制信息，请参见使用限制。