在规划 SQL Azure 应用程序时，我应该牢记哪些性能注意事项？Azure 存储、工作人员和 Web 角色看起来非常可扩展，但如果最终他们使用一个数据库......它看起来像是瓶颈。
我试图找到有关以下内容的数字：
但没有运气。
例如，我正在计划和应用程序使用非常高级别的插入，但我每次都需要返回聚合函数的结果（例如：列中具有相同键的所有记录的总和），所以我不能与桌子存储一起去。
批处理是一种选择，但时间响应也很关键，所以我担心数据库会因大量连接而膨胀。
分片是另一种选择，但即使插入量很大，数据量也很小，4到6列有一个PK，没有FK。因此，对于分区来说，即使是 1Gb 的数据库也是一种过度杀伤（和多付：D）。
当我面对这类应用程序时，我应该牢记哪些性能关键？
干杯。
如果发生任何形式的资源争用，SQL Azure 将限制您的连接（这包括重负载，但也可能在您的数据库物理移动时发生）。限制是不确定的，这意味着您无法预测是否以及何时发生这种情况。限制时，SQL Azure 将断开您的连接，要求您执行重试。由于底层基础设施的灵活性，支持的连接数和带宽不是“按设计”发布的。话虽如此，该设置针对高可用性而不是高吞吐量进行了优化。
如果突发发生在已知时间，您可能会考虑仅在这些突发期间进行分片，并在突发发生后整合数据。处理此问题的另一种方法是，当且仅当发生限制时才开始排队/批处理写入。您可以为此使用 Azure 队列以及辅助角色稍后清空队列。这种“溢出机制”具有在发生节流时自动接合的优点。
作为替代方案，您可以使用 Azure 表存储并保留一个单独的运行总计表，您可以报告该表，而不是对数据执行聚合以返回所有记录的所需总和（由于缺乏锁定桌子虽然）。
很抱歉说明了这一点，但第一步是测试你是否在你的场景中遇到了限制。我会尝试溢出解决方案。
即使在云中，同时实现可扩展性和性能也是非常困难的。您的问题主要是关于可伸缩性的，因此您可能希望设计您的应用程序，使您的数据“最终”保持一致，例如使用队列。工作角色将侦听传入的插入请求并异步执行插入。
为了最大限度地减少到数据库的往返次数并优化连接池，请确保对插入进行批处理。因此，您可以一次发送 100 个插页。另请记住，SQL Azure 现在支持 MARS（多个活动记录集），因此您可以将多个 SELECT 在一个批次中返回给调用代码。批处理和 MARS 的使用应该将数据库连接的数量减少到最低限度。
分片通常有助于读取操作；对于插入来说不是很多（尽管我从未使用分片对插入进行基准测试）。因此，我不确定分片是否能满足您的要求。
请记住，Azure 产品首先是为多租户环境中的可扩展性和合理性能而设计的，在该环境中，您的数据库与同一服务器上的其他人共享。因此，如果您需要保证响应时间的强大性能，您可能需要重新评估您的托管选择，或者根据 tijmenvdk 的建议测试 Azure 的性能边界以满足您的需求。