好。 我们知道数据库大小，并发用户数量，每分钟事务数量; 应该select处理器数量，RAID，RAM，镜像和集群。
没有确切的规则，但可能是没有规则呢？
在我的实践中，我都有“遗留”系统，经过一些检查和采访，我可以形成一个硬件和devise如何改进的意见。
但是每次当我遇到“绝对”新系统（我猜这里没有新系统，但有时也是这样的任务），我不能说任何可信任的东西。 所以我很有趣，人们如何处理这样的任务？ 他们在他们的经验上绘制任务或者拥有一些基本公式？
它可能更多地取决于交易types和数据库的devise。 相关的事情还有它的读和写的多less（对于RAIDconfiguration来说非常重要），有没有复杂的JOIN等等。这关系到数据库和应用程序devise的质量，就像是有多less并发用户一样和交易。 因此，我想说通用OLTP数据库没有规则，只要为OLTP数据库和应用程序制定规则（以及可能的优化）即可。 想象一下，如果你没有索引 – 你的数据库将performance的很差。
从一个testing服务器开始，使用一个已知的负载，并使用Profiler查看瓶颈的位置。 然后修复这些，并增加负载。
如果你有一个特定的testing服务器，你可以做一些testing，而不必安装SQL或部署任何数据库。
我听说有关sqliosim.exe工具的好东西，用于模拟全新的操作系统上的SQL活动，没有任何运行。 我从来没有testing过，因为我没有这样的环境，但configuration起来并不难。
结果将指导您确定CPU，内存或磁盘是否足够您的系统。
你需要有一些基准知道你需要多lessCPU，内存或磁盘。 但是，在磁盘configuration的OLTP数据库上有一些最佳实践：RAID 10和RAID 5似乎是最佳select。
适用于增加写入活动的RAID 10 – 日志文件（100％是写入活动）和数据文件（如果写入活动超过I / O操作的10％）。
适用于增加读取活动的Raid 5 – 数据文件（如果写入活动less于I / O操作的10％）。
Paul Randal的博客可以帮助你，因为他做了很多硬件testing，得出了合理的结论： http : //www.sqlskills.com/BLOGS/PAUL/category/Performance.aspx