为了提高SQL性能，为什么不仅仅放置大量RAM而不是拥有更快的硬盘？

人们不断告诉我，为了提高SQL Server的性能，请使用RAID 5等来购买最快的硬盘。

所以我在想，为什么不花所有的钱购买RAID 5和超级双倍速硬盘（顺便说这并不便宜），为什么不仅仅获得数吨的RAM？我们知道，SQL Server将数据库加载到内存中。内存比任何硬盘都要快。

为什么不在服务器上填充100 GB的RAM？然后，仅使用带有RAID 1的常规SCSI硬盘。这会便宜又快吗？

您的分析在某种程度上是可以的，因为它绝对可以使事情变得更快。不过，您仍然必须考虑其他几个问题：

1. 并非每个人都负担得起足够的内存。当您有数TB的数据时，必须将其放入磁盘一段时间。如果您没有太多数据，那么一切都足够快。

2. 磁盘的写性能仍然会受到磁盘的限制，因此您可以保证实际存储了数据。

如果您的数据集很小，或者不需要将其保存在磁盘上，那么您的想法就没错。VoltDB之类的工具正在努力减少RDBMS实现中较早的假设所产生的开销，这些开销限制了纯内存性能。

（顺便说一句，告诉您使用RAID-5来提高数据库性能的人可能不是听这个主题的好人，因为它几乎永远不是最佳选择-它具有良好的读取性能，但是写入性能和写入性能很差。几乎始终是生产的限制-因为您可以将RAM放入缓存中以解决大多数读取端性能问题。）

简短版：考虑工作集大小。长版：您的数据有多大？如果它可以容纳现代服务器的内存，是的，您绝对正确。不幸的是，最大的Xeon现在可以处理2TB的RAM，而这不再是一个庞大的数据集。如果您无法购买足够大的机器以将整个工作装置存储在RAM中，那么您将不得不解决大脑而不是钱包的问题。

如果您想提高速度：

• 增加RAM，以便至少经常使用的索引可以完全适合RAM（例如，在我使用的系统上，对于350GB数据库，32GB RAM足够了，因为索引是您在RAM中所需的，而不是原始数据）
• 将RAID10与任何磁盘一起使用（磁盘越快越好）
• 避免 RAID5
• 将mdf，ldf和temp DB拆分为离散的主轴集（例如：tempdb在其自己的RAID1集上，ldf在其自己的RAID1或RAID10主轴集上，mdf在RAID 10集上，且磁盘总数至少为4）

按照这些步骤，SQL Server将运行。

然后，如果需要，添加更多的RAM ...但是首先执行上述操作，您可能会发现自己已完成。

RAM是新磁盘，磁盘是新磁带。

在http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids中。请注意那是六年前。是的，我们有一些数据库系统会尝试（并努力）将整个数据集保留在RAM中，而不是使用磁盘，而将其分片到多台计算机上，因为磁盘无论如何大小都会变慢。您需要将数据集写到磁盘上，但是就像上面的座右铭一样，它更像是后台备份任务，而不是在线操作。通过仅在这些数据库中附加日志来实现持久性（我认为是MongoDB和Redis，但还有更多）。

这个问题类似于一个基本问题，在过去的5-10年中，该问题导致了数据库体系结构的大量研究和开发。既然可以在许多用例中将整个数据库存储在RAM中是可行的，则需要围绕在RAM中工作来设计数据库，而不是简单地将较旧的继承体系结构应用于基于RAM的存储。

近年来，正如许多更小，更专用的语言被广泛采用一样，我们正在进入一个时代，将需要更多的专用数据库。

为了进一步阅读该主题，我建议您发表学术论文《建筑时代的终结（完全重写的时候了）》。读起来并不难。

目前尚不清楚此问题是否专门针对SQL Server。原始海报应对此进行澄清。

丹尼尔·皮特曼写道：

如果您的数据集很小，或者不需要将其保存在磁盘上，那么您的想法没有错。诸如VoltDB之类的工具正在努力减少RDBMS实现中较早的假设所产生的开销，这些开销限制了纯内存性能。

减少RDBMS实现中较早的假设所产生的开销正是VoltDB的设计目标，但它确实可以水平扩展，而对数据大小没有体系结构上的限制，并且可以使用快照和命令日志记录持久保存到磁盘上，以实现完全持久性。

如果您可以使服务器具有足够的RAM来容纳数据集的最热部分，那么您会很好的。同样，RAID 1和5并不是最快的数据整理方式-RAID 0更快，但是，那么，您必须考虑文件系统故障导致数据库崩溃的几率更高-这不是一件好事。如果您有足够的驱动器和控制器，则可以将RAID 0阵列设置为RAID 1或RAID 5。

您甚至可以在此处进行复制-将内容写入磁盘密集型服务器，该服务器复制到一个或多个内存密集型服务器，在其中运行复杂的查询。

可悲的是，RDBMS似乎处在一个大铁杆领域-横向扩展并不容易。

这是“这取决于您在做什么”的情况。也许“正确”的建议是完全避免使用SQL，并使用memcache / redis / etc！

我同意您的意见，即额外的RAM将有很大帮助，特别是如果您能够将整个工作集读取到RAM中的话。是的，它仍然必须写数据，但是如果您大多数读操作，则写操作不会与磁盘I / O争用。

但是，磁盘性能通常是SQL服务器上的瓶颈，并且比RAM等其他事情更难在以后升级（如果您的服务器未完全装有DIMM）。

有很多关于RAID5速度慢的评论，但我会说并非总是如此，因此在做详尽的声明之前要小心。带有快速RAID卡和大量BBWC的真正高端服务器有时在RAID5（或具有> 4个磁盘的RAID50）中的运行速度比在RAID10中的运行快得多。

多年来，我个人经历了缓慢的RAID5阵列，但在2009年〜4个146G SAS磁盘对DL360 G5进行基准测试之后，我们不得不仔细检查我们的测试。实际上，在几乎所有测试中，使用RAID5阵列的速度都比使用RAID10的速度快。BBWC和快速奇偶校验计算使服务器可以将4个磁盘用作RAID5阵列，比RAID10更有效。一些测试显示RAID5的吞吐量提高了50％，而几乎没有一个慢。较慢的测试仅降低5-10％。

我要提醒那些发表声明的人，说RAID5速度很慢，每个人都在线上说，但是在每种情况下都不是真的。

您有一个混合袋糖果可供选择，并且实际上取决于您想要的口味。

1. 数据库将具有配置以缓存查询以及此缓存存在的位置，内存或硬盘驱动器。
2. RAID 5并不总是最快的，但是RAID 0（JBOD）是一个条带并且速度很快，因为RAID 5也是一个条带，所以想法基本相同。
3. RAID 1不会提高您的速度，它只是一个镜像。
4. SQL性能基于索引，这是要检查的第一件事。在关系数据库中非常重要。
5. 不要索引所有内容，过度索引还会降低速度，因为索引会变得超载。
6. 有时，使用SQL Joins会使数据库变慢。使用编程循环一组最小索引结果可提高速度。
7. 如果您不付钱，虚拟服务器将是速度上的噩梦。

只需先投入知识（免费），然后再分叉现金。1.了解数据库的配置，然后查看当前配置以进行优化。2.查看编程和sql语句，使用模拟相关操作的简单脚本进行单元测试，甚至可能不是您认为的问题。如果简单的脚本使用SQL Joins占用时间，将其拆分并通过编程循环执行相同的操作即可。这对内存有帮助。3.查看托管计划和服务器。在Linux控制台中使用ps aux，看看是否有东西在消耗您的内存和处理器。

绝对硬盘可以提高速度，但在虚拟服务器空间中则取决于您。除非您为其配置服务，否则内存不会提高速度。带有快速总线的条带化RAID（0,5），RPM和同步读/写可帮助实现这一点。具有良好的1、2、3级缓存的核心处理器将有助于处理瓶颈。我能听到至强的声音吗？

总体而言，您必须牢记大小和可伸缩性。尽管您似乎开始时需要的存储空间很小，但是您的数据将非常快速且呈指数增长。数据库最好使用原子数据，这些数据被分解为尽可能小的大小。由于体积小，它在数据仓库中的传输速度更快。然后，您还要考虑数据库结构。将来，您可能会链接到外部数据库，这就是为什么结构也至关重要的原因。在这种情况下，如果一半的数据位于数据集市之外，则对您的查询几乎没有影响。查询数据时，重点不是将存储的数据保留在RAM中；而是将数据保留在RAM中。而是查询应该快速访问和返回数据。

• 您确实并不总是将RAID 5用作数据。除先前提到的备份内容外，还取决于数据及其重要性。RAID 1可以使用并且可以使用。
• 您将必须升级查询范围内的所有服务器以提高速度。由于许多数据不在您的控制范围内，因此它将成为数据集市之外的瓶颈。（如果您自己升级）