人们总是告诉我，为了提高SQL服务器的性能，用RAID 5等购买最快的硬盘。
所以我在想，不是把所有的钱花在RAID 5和超级快速硬盘上（这种方式并不便宜），为什么不只是得到大量的内存呢？ 我们知道一个SQL服务器将数据库加载到内存中。 内存比任何硬盘都快。
为什么不在一台服务器上像100 GB的内存？ 那么只需使用RAID 1的普通SCSI硬盘即可。难道这样便宜又快吗？
你的分析没有问题 – 总之，这绝对会让事情变得更快。 但您仍然需要解释其他一些问题：
不是每个人都有足够的记忆 当你有多个TB的数据时，你必须把它放在磁盘上。 如果你没有太多的数据，任何事情都足够快。
数据库的写入性能仍然受到磁盘的限制，所以您可以保证数据实际存储的承诺。
如果你有一个小的数据集，或不需要坚持在磁盘上，你的想法没有任何错误。 诸如VoltDB之类的工具正在努力减lessRDBMS实现中较旧的假设，这限制了纯内存性能。
（另外，有人告诉你使用RAID-5来进行数据库性能的testing可能不是最好的select，因为它几乎不是最好的select – 它具有良好的读取性能，但写入性能差，而且写入几乎总是生产约束 – 因为您可以将RAM放入caching中以解决大多数读取性能问题。）
短版：考虑工作集的大小。 长版本：你的数据有多大？ 如果它能适应现代服务器的记忆，是的，你是绝对正确的。 不幸的是，目前最大的至强处理器可以处理2TB的内存，而这并不是那么大的一个数据集。 如果你不能购买足够大的机器来存放你的整个工作集，你就不得不用你的大脑解决问题，而不是你的钱包。
如果你想要速度：
按照这些步骤，SQL Server将飞行。
然后，如果你想要的话，增加更多的内存……但是先做上面的事情，你可能会发现你已经完成了。
RAM是新磁盘，磁盘是新磁带。
在http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids 。 请注意六年前。 是的，我们有数据库系统尝试（并努力尝试）将整个数据集保存在RAM中，而不是碎片到多个机器，而不是使用磁盘，因为磁盘的大小反正慢一些。 您需要将数据集写入磁盘，但正如上面的座右铭所述，这更类似于后台备份任务，而不是在线操作。 通过追加这些数据库的日志来实现持久性（我在想MongoDB和Redis，但是还有更多）。
这个问题类似于过去5 – 10年以来在数据库架构方面进行了大量研究和开发的基本问题。 现在可以将整个数据库存储在RAM中作为许多用例，数据库需要devise在RAM中工作，而不是简单地将更旧的inheritance体系结构应用于基于RAM的存储。
就像许多小型和特殊用途的语言近年来被广泛采用一样，我们正在进入一个更加需要特殊用途的数据库。
关于这个主题的进一步阅读，我推荐学术论文“build筑时代的终结”（现在是完全重写的时代） 。 这不是一个困难的阅读。
目前还不清楚这个问题是否专门针对SQL Server。 原来的海报应该澄清这一点。
丹尼尔·皮特曼写道：
如果你有一个小的数据集，或者不需要把它保存在磁盘上，那么你的想法是没有问题的。 诸如VoltDB之类的工具正在努力减lessRDBMS实现中的老式假设>限制纯内存性能的开销。
减lessRDBMS实现中较早假设的开销，这正是VoltDB的devise目标，但它可以水平扩展，对数据大小没有体系结构限制，并且可以使用快照和命令日志logging来保持磁盘的完全持久性。
如果你可以得到一个足够RAM的服务器，至less可以保存你数据集中最热的部分，那么你会好起来的。 此外，RAID 1和RAID 5不是最快的方式来安排您的数据 – RAID 0是更快，但是，那么，你将不得不考虑文件系统故障，抹去你的数据库更高的几率 – 不是一件好事情发生。 如果您有足够的驱动器和控制器，则可以将RAID 1或RAID 5作为RAID 0arrays。
您甚至可以在这里使用复制 – 执行写入到磁盘繁重的服务器，该服务器将复制到一个或多个内存繁重的服务器，在该服务器上运行复杂的查询。
令人遗憾的是，关系数据库似乎处于大铁的领域 – 它们并不容易水平生长。
这是“这取决于你在做什么”的情况。 也许“正确”的build议是完全避免SQL，并使用memcache / redis / etc！
我同意你的意见，额外的内存将帮助很多，特别是如果你能够读取整个工作集到RAM中。 是的，它仍然需要写入数据，但是如果你主要读取数据，写入操作将不会有磁盘I / O的争用。
但是，磁盘性能往往是SQL服务器的瓶颈，并且比以后更难以升级的其他内存（如果您的服务器没有完全装满DIMM），则性能会更差。
关于RAID5缓慢的评论有很多，但我想说这并非总是如此，所以在做清晰的陈述之前要小心。 具有快速RAID卡和大量BBWC的真正高端服务器有时在RAID5（或RAID50> 4磁盘）方面比在RAID10中快得多…
多年来，我亲身经历了缓慢的RAID5arrays，但在2009年以4个146G SAS磁盘对DL360 G5进行基准testing之后，我们必须仔细检查我们的testing。 事实上，arrays在几乎所有的testing中都比RAID10更快。 BBWC和快速奇偶校验计算允许服务器使用4个磁盘比RAID10更有效地作为RAID5arrays。 有些testing显示，使用RAID5的吞吐量提高了50％，几乎没有一个是较慢的。 慢的testing只有5-10％的折扣。
我会告诫那些做出全面报告的人，说RAID5很慢，大家都在网上说，但是在任何情况下都不是这样。
你有一个糖果混合袋可供select，真的取决于你想要的味道是什么。
在分出现金之前，简单地投入知识（免费）。 1.了解数据库的configuration，并查看当前的configuration以优化。 2.看看编程和sql语句，用简单的脚本进行unit testing，模仿相关的操作，甚至可能不是你所想的问题。 如果简单脚本使用SQL连接占用时间，则将其拆分，并使用编程循环执行相同的操作。 这是内存可以帮助3.看看主机scheme和服务器。 在Linux控制台中使用ps aux，看看是否有东西吸吮你的内存和处理器。
绝对硬盘提高了速度，但在虚拟服务器空间中无法满足您的需求。 内存不会提高速度，除非您为其configuration服务。 条纹RAID（0,5），RPM和同步读/写快速总线帮助。 具有良好的l1，l2，l3caching的核心处理器将有助于处理瓶颈。 我可以听到至强！
总体而言，您必须牢记尺寸和可扩展性。 虽然您似乎从小型存储需求开始，但您的数据将以指数forms快速增长。 数据库最好使用primefaces数据，这些数据是按照最小可能的大小分解的。 由于体积小，数据仓库内的传输速度更快。 然后，你还要考虑数据库结构。 将来，你可以链接到外部数据库，这就是为什么结构也是至关重要的。 在这种情况下，如果有一半的数据位于数据集市之外，那么对于您的查询来说就没什么区别了。 当查询数据时，重点不在于将存储的数据保存在RAM上; 相反，查询应该快速访问和返回数据。