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