我们正在使用VM在Azure云中设置SQL服务器。当我们确定数据/ logs / tempdb的最佳设置时，我们遇到了很多博客帖子，建议将tempdb放在Azure提供的Temporary Storage驱动器上。然而，更深入的研究显示this information from Microsoft据说不应该这样做。
所以我们留下了以下问题：
答案 0 :(得分：6)
由于最初的建议是将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最佳实践的编译。
答案 1 :(得分：5)
更新：现在，临时驱动器可用作D系列Azure VM的SSD，@ CSharpRocks引用的白皮书略显过时。有关最近的建议（截至2014年年中至2015年中），请参阅以下两篇文章：
上面的文章明确提到将tempdb和Buffer Pool Extensions放在D：\上。摘录：
仅在D驱动器上存储tempdb和/或Buffer Pool Extensions 使用D系列虚拟机（VM）。与其他VM系列不同， D系列VM中的D驱动器是基于SSD的。这可以改善 大量使用临时对象的工作负载的性能 有工作集，不适合记忆。
答案 2 :(得分：1)
2017年：
我有一个长期运行的存储过程，它是tempdb密集型的。在OS驱动器上设置Tempdb，就像Azure默认配置它一样，在使用SDD磁盘的DSv2计算机上，查询运行大约1.5分钟。
将Tempdb移动到临时存储（并且不做任何其他操作）将查询更改为在57秒内运行，因此性能提高了33％。在两种情况下都重复运行查询，并且这些数字的时间一致（给予或接受）。
将TempDB置于临时存储上需要特别考虑启动SQL Server。有两种方法。一种是将文件指向D的根目录，并为SQL服务器提供本地管理权限。如果您已经有其他东西启动SQL Server进程而不仅仅是自动服务启动，那么这是您要考虑的方案。否则会引起安全人士的注意。
第二个选项是将SQL Server服务设置为手动启动，然后编写powershell脚本以启动它，并将该PowerShell脚本放在计划任务上以便在启动时运行。在启动SQL Server之前，powershell脚本首先会确保临时存储上存在该目录。
它已在另一个答案中链接，但this document已于2017年更新，并且它没有正式推荐这种TempDb设置，而只是将其从操作系统分区移开。但是，它说：
如果您的工作负载大量使用TempDB（例如，对于临时对象或复杂连接），将TempDB存储在D驱动器上可能会导致更高的TempDB吞吐量和更低的TempDB延迟。
我的表现经历证实了最后一行。