我正在为SQL Server计算机购买SSD，我应该比较哪些基准？ 高/低队列深度？ 随机/连续传输速率？ IOPS？
IOPS非常多。
队列深度是无关紧要的 – 基本上，一些高端系统在更多队列排队的情况下效果更好。 这不会给你任何没有上下文的明智的信息。
传输率取决于IOPS – 有人必须先读/写这些东西。
最后，随机IO总是运行到IOPS。 IOPS直接传输到需要时的传输速率。 请注意，SQL Server始终为企业提供64k IO或多个IO。 所以，4kb等是不相关的。 从那里你可以拉所有其他信息。 响应时间太慢，排队 – 没有足够的IOPS可用。
您需要的基准是以下工作负载的IO延迟：
您也可能对这些工作负载的吞吐量（MB / s）感兴趣：
对于所有的写入，请记住，在IO命中磁盘之前caching到易失性内存可能会使MB / s看起来比实际更高。 随机IO与SSD在顺序IO上一样好。
在TechNet上有一篇很好的文章，这篇文章已经不再被维护，但是这些文章还不能让您了解IOPS和磁盘饱和度如何影响SQL Server磁盘IO性能。
SQL Server最佳实践文章（TechNet）
简介：I / O系统对于SQL Server的性能很重要。 为SQL Serverconfiguration新的服务器时，或者在添加或修改现有系统的磁盘configuration时，最好在部署SQL Server之前确定I / O子系统的容量。 本白皮书讨论validation和确定I / O子系统的容量。 许多工具可用于执行这种types的testing。 本白皮书重点介绍了SQLIO.exe工具，还比较了所有可用的工具。 它还涵盖了SQL Server 2005的基本I / Oconfiguration最佳实践。
文章接着解释说，SQL Server将读取对应于Extent（本身为8 x 8页;页面= 8 kb）的64 kb的倍数。 了解页面和范围
SQL Server将读取64kb的数据（这就是为什么你应该用64kb的块大小来格式化你的磁盘），并且根据查询的性质（64kb，128kb，256kb，512kb，甚至1024kb企业版）。
您可能会考虑运行一个工具来testing各种IO模式（读/写;随机/顺序; 8 kb – 1024 kb），具体取决于您的SQL Server版本，然后比较HDD与SSD的结果。
有一个旧build议，事务日志文件的写延迟应该在1-5毫秒（build议1毫秒）之间，数据文件的读延迟应该在5-20毫秒（推荐10毫秒）之间。
测量磁盘延迟。 值越低越好，但这可能会有所不同，取决于发出的I / O的大小和性质。 不同的存储configuration数量也不同（caching大小/利用率可能会对此产生很大的影响）。
在调整好的I / O子系统上，理想的值是：
•1到5毫秒的日志（理想情况下1毫秒高速cachingarrays）
•OLTP系统上的数据为4-20毫秒（理想情况下为10毫秒或更less）
•DSS（决策支持系统）types为30 ms或更less。 这里的延迟可能会有很大的不同，这取决于系统发出的同时查询的数量。 应该调查总吞吐量小于预期的持续数值。考虑这些结合你的特定系统的正常情况。
确保监视磁盘延迟以进行趋势分析。 可以使用SQL Server 2005中的sys.dm_io_virtual_file_statsdynamicpipe理视图来查找特定于SQL Server数据文件的I / O数量和延迟。
本文列出了各种计数器来监视哪些将为您提供一个基准，然后，如果将磁盘从HDD更改为SSD，则可以从中确定性能提升。
您需要以下组合：
计划在旧HDD系统上监视这些值，然后将它们与SSD系统上的值进行比较并比较这些值。
简短的答案是“它取决于”
不幸的是，在不了解您的使用模式的情况下，提出“理想”解决scheme几乎是不可能的
有些事情要记住
分离你的数据，日志和操作系统。 您可以将数据和操作系统放在旋转磁盘上，只将日志放在SSD上，这样可以降低成本。 无论如何，即使您正在使用旋转磁盘，也应该真的这样做，将所有部分分离到自己的卷上，如果可以承受，则分别使用RAID 10。
如果您可以将整个数据库加载到RAM中，则可以通过将RAM添加到您的解决scheme来更好地服务，那么速度比SSD或HDD所能达到的要快得多。 你可以用几种不同的方法来完成这个。
如果你在整个SSD的路线下，确保你的备份是好的。 最好这样做:)