我們正在使用VM在Azure雲中設置SQL服務器。當我們確定數據/日誌/ tempdb的最佳設置時，我們遇到了許多博客帖子，建議將tempdb放置在Azure提供的Temporary Storage驅動器上。然而更深入的研究顯示this information from Microsoft據說這不應該完成。臨時存儲上的Azure VM SQL Server Tempdb
所以我們留下了以下問題：
由於最初的建議是將tempdb放置在D：驅動器上，因此存在一些困惑。這不再是事實。有關最新的信息，我建議你閱讀「在Windows Azure虛擬機的SQL Server性能指南」位於白皮書這裏：http://msdn.microsoft.com/en-us/library/windowsazure/dn248436.aspx
下面是與tempdb的部分摘錄：
正如在節中提到的Windows Azure虛擬機磁盤和緩存設置，我們建議您將tempDB放在操作系統磁盤或數據磁盤上，而不是臨時磁盤（D :)。以下是基於我們使用SQL Server測試工作負載進行內部測試的建議的三個主要原因。
•性能差異：在我們的測試中，我們注意到您可以獲得與D：相同的性能級別，如果不是來自操作系統或單個數據磁盤的更多IOPS。但是，D：驅動器的性能無法保證與操作系統或數據磁盤一樣可預測。這是因爲D：驅動器的大小和從中獲得的性能取決於您使用的虛擬機的大小。
•虛擬機停機情況下的配置：如果虛擬機由於計劃或非計劃原因而關閉（爲了使SQL Server重新創建D：驅動器下的tempDB），SQL Server服務啓動需要具有本地管理員權限。另外，本地SQL部署的常見做法是將數據庫和日誌文件（包括tempDB）保存在單獨的文件夾中，在這種情況下，需要在SQL Server啓動之前創建該文件夾。對於大多數客戶來說，這種額外的重新配置開銷並不值得回報。
•性能瓶頸：如果將tempdb放置在D：驅動器上，並且應用程序工作負載大量使用tempDB，則可能會導致性能瓶頸，因爲D：驅動器可能會在IOPS吞吐量方面引入約束。相反，將tempDB放在操作系統或數據磁盤上以獲得更大的靈活性。有關優化tempdb的配置最佳實踐的更多信息，請參閱編譯SQL Server TempDB IO最佳實踐。
更新：現在，臨時驅動器可用作D系列Azure虛擬機的SSD，@CSharpRocks引用的白皮書略有過時。有關詳情，請最近的建議以下兩篇文章（遲-2014的通2015年中旬）：
的文章提到在D：\上放置tempdb和Buffer Pool Extensions。摘錄：
當 使用D系列虛擬機（VM）時，僅在D驅動器上存儲tempdb和/或緩衝池擴展。與其他VM系列不同， D系列VM中的D驅動器是基於SSD的。這可以改善大量使用臨時對象的工作負載的性能，或者 具有不適合內存的工作集。
2017年：
我有一個長期運行的存儲過程是tempdb的密集。在操作系統驅動器上設置Tempdb（如Azure默認配置的那樣），在使用SDD磁盤的DSv2機器上，查詢運行時間約爲1分半鐘。
將臨時數據庫移動到臨時存儲器（並且什麼都不做）將查詢更改爲在57秒內運行，因此性能提高了33％。在這兩種情況下，查詢都反覆執行，並且這些數字的時間安排是（一致或一致）。
將TempDB放在臨時存儲上需要特別考慮啓動SQL Server。有兩種方法。一種是將文件指向D的根目錄，並賦予SQL服務器進程本地管理權限。如果你已經有其他的東西在啓動SQL Server進程，而不僅僅是一個自動的服務啓動，那麼你就需要考慮這種情況。否則，它會提高安全性眉毛。
第二種方法是將SQL Server服務設置爲手動啓動，然後編寫一個powershell腳本以啓動它，並將該powershell腳本放在計劃任務上以在啓動時運行。在啓動SQL Server之前，powershell腳本將首先確保臨時存儲上存在該目錄。
它已經鏈接到另一個答案，但this document更新爲2017年，它並沒有正式推薦這種TempDb的設置，而只是將其從OS分區移出。然而，它說：
如果你的工作量使大量使用tempdb的（例如，用於臨時對象或複雜的連接），在d驅動器上存儲的TempDB可能會導致更高的TempDB吞吐量和更低的延遲TempDB的。
我的表現經驗證實了最後一行。
儘管基本概念是正確的，但2015年4月的文章有很多錯誤。該任務未配置爲在用戶未登錄時運行，腳本的定義需要雙引號而不是單引號，並且實際上並不測試該場景（提示，向臨時存儲添加垃圾文件並查看如果它被破壞）。 – Yishai