在 the documentation它指出 Azure 表存储分区的最低速度为 500 次操作/秒。
如果我的数据分区正确，每个分区上的并行操作是否不会相互影响？
例如，如果我必须在分区 A 上执行昂贵的全表扫描(最多 500 个实体/秒)，分区 B 上发生的任何操作的性能是否会受到影响？
存储帐户的操作限制为每秒 5000 次。这是否本质上意味着我最多可以使用 10 个分区，然后它们才会开始影响彼此的性能？
最佳答案
作为一般规则，您希望尽可能避免表扫描。它们是非常昂贵的操作(特别是如果您有很多分区)。从表压力的角度来看，并没有那么严重，但它们的总延迟非常高(如下所述)。也就是说，有时根本无法避免它。
我们更新了存储架构并提高了一系列目标限制。
每个存储帐户现在为 20k IOPS/秒。 每个分区现在为 2k/秒
分区的交互方式有点微妙，取决于它们的使用方式(并随着时间的推移而变化)。
Azure 存储有两个阶段 - 一组服务器处理范围，另一组设置实际存储(即 3 个副本)。当表处于冷状态时，所有分区都可以由一台服务器提供服务。当分区承受持续压力时，系统将开始自动将工作负载(即分片)分散到其他服务器。分片是在分区边界上创建的。
对于低/中压力，您可能不会达到分片的阈值或仅达到最低分片次数。此外，访问模式也会产生一些影响(如果您仅附加，分片将无济于事)。跨所有模式的随机访问将是迄今为止最好的扩展。当系统重新平衡时，您将收到503响应几秒钟，然后操作将恢复正常。
如果进行表扫描，实际上会多次往返表。当查询到达分区末尾时，将返回响应，其中包含找到的任何数据(如果不满足条件，则不返回任何数据)和继续 token 。然后一次又一次地重新提交查询(并使用 token 返回)，直到到达表的底部。这是由 SDK 抽象出来的，但如果您直接进行 REST 调用，您就会看到它。
从表性能的角度来看，扫描只会影响当前正在扫描的分区。
为了加速命中多个分区的广泛查询，您实际上可以将其分解为多个并行访问(例如每个分区一个线程)，然后在客户端中合并。实际上，这取决于您返回的数据量、表有多大等等。
关于performance - Azure 表存储分区单独性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14963586/