在規劃SQL Azure應用程序時，應記住哪些性能因素？ Azure存儲以及工作者和Web角色看起來非常具有伸縮性，但如果最終他們使用的是一個數據庫......看起來就像是瓶頸。SQL Azure性能注意事項
我試圖找到有關的數字：
但是沒有運氣。例如，我正在計劃和使用非常高級別的插入的應用程序，但是我需要每次都返回聚合函數的結果（例如：列中具有相同鍵的所有記錄的總和），所以我不能和桌子一起存放。
批處理是一種選擇，但時間響應也非常重要，所以恐怕數據庫會出現大量連接。
分片是另一種選擇，但即使插入數量很大，數據量也非常小，4到6列只有一個PK而沒有FK。因此，即使1Gb數據庫對於分區來說也是一個矯枉過正（以及多付：D）。
當我面對這些類型的應用程序時，應該記住哪些性能鍵？
乾杯。
實現可擴展性和性能可能非常困難，即使在雲中也是如此。你的問題主要是關於可伸縮性，所以你可能想要設計你的應用程序，以便你的數據變得「最終」一致，例如使用隊列。一個工作者角色會監聽傳入的插入請求，並會異步執行插入操作。
爲了儘可能減少往返數據庫的次數並優化連接池，請確保批量插入。所以你可以一次發送100個插頁。另外請記住，SQL Azure現在支持MARS（多個活動記錄集），因此您可以將單個批處理中的多個SELECT返回給調用代碼。批處理和MARS的使用應將數據庫連接的數量降至最低。
分片通常有助於讀操作;沒有太多的插入（儘管我從來沒有用分片對插入進行基準測試）。所以我不確定sharding會如何幫助你滿足你的需求。
請記住，Azure產品首先是爲多租戶環境中的可擴展性和合理性能而設計的，其中您的數據庫與同一服務器上的其他人共享。因此，如果您需要強大的性能和確保的響應時間，您可能需要重新評估您的主機選擇，或者確實按照tijmenvdk的建議測試Azure的性能邊界以滿足您的需求。
如果發生任何形式的資源爭用（包括負載過重，但也可能在您的數據庫實際移動時發生），SQL Azure會限制您的連接。節流是非確定性的，這意味着您無法預測是否以及何時發生這種情況。當調節時，SQL Azure會斷開您的連接，要求您執行重試。由於底層基礎設施的靈活性，支持的連接數量和帶寬不會「按設計」發佈。話雖如此，該設置針對高可用性而非高吞吐量進行了優化。
如果突發事件發生在已知時間，那麼您可能會考慮在突發事件期間分片並在突發事件發生後整合數據。處理這種情況的另一種方法是，當且僅當限制發生時纔開始排隊/批量寫入。您可以使用Azure隊列以及輔助角色稍後清空隊列。如果發生節流，這種「溢流機制」具有自動接合的優點。
作爲一種替代方案，您可以使用Azure表存儲並保留一個單獨的運行總計表，您可以報告而不是通過對數據執行彙總來返回所有記錄所需的總和（這可能會因爲儘管表上沒有鎖定）。
陳述明顯的道歉，但第一步將測試是否在您的情況下進入節流。我會嘗試一下溢出解決方案。