SSD上的SQL Server数据库-每个表的单独文件有什么优势？

我正在创建一个数据库，其中大约有30个表，每个表包含数千万行，每个表包含一个重要列和一个主键/主键列，以在面对繁重的情况时最大化查询效率更新和插入，并大量使用聚集索引。其中两个表将包含可变长度的文本数据，其中一个表包含数亿行，而其余表仅包含数字数据。

由于我真的想从我可用的硬件（大约64GB的RAM，一个非常快的SSD和16个内核）中挤出所有性能的下降，所以我在考虑允许每个表都有自己的文件，这样无论我要加入2、3、4、5或更多表，每个表将始终使用单独的线程读取，并且每个文件的结构将与表内容紧密对齐，从而有望最大程度地减少碎片并使其更快使SQL Server添加到任何给定表的内容。

一个警告，我被困在SQL Server 2008 R2 Web Edition上。这意味着我不能使用自动水平分区，这将其排除在性能之外。

是否会在每个表中使用一个文件实际上使性能最大化，或者我是否忽略了使之多余的内置SQL Server引擎特性？

其次，如果每个表使用一个文件是有好处的，为什么create table只给我选择将表分配给文件组而不分配给特定逻辑文件的选项？这将需要我为方案中的每个文件创建一个单独的文件组，这向我暗示SQL Server可能没有想到我所假定的优势将来自于我的建议。

我正在考虑允许每个表都有自己的文件，这样无论我加入2、3、4、5或更多表，总是使用单独的线程读取每个表，并且每个文件的结构都会与表内容紧密对齐，这有望最大程度地减少碎片，并使SQL Server更快地将其添加到任何给定表的内容中

你到底在说什么 不确定从何处获取信息，但是您当然应该丢弃该信息源。您在这里所假设的一切实际上都不正确。

如果您想阅读有关SQL Server SSD性能的很好的讨论，这里有几个博客系列。像往常一样，Paul Randal的文章是最受欢迎的：

• 基准测试：SSD简介（第1b部分：未超载的日志文件阵列）
• 基准测试：SSD简介（第1部分：未超载的日志文件阵列）
• 基准测试：SSD简介（第2部分：顺序插入）
• 基准测试：SSD介绍（第3部分：具有等待统计信息的随机插入）
• 基准测试：SSD上的多个数据文件（以及最新的Fusion-io驱动程序）

布伦特（Brent）在以下主题上也做了不错的演讲：SSD上的SQL：疯狂的爱情，还有更多内容。

通过所有这些演示，您将很快注意到它们都集中在写入上，因为这是SSD性能的体现。您的帖子措辞几乎完全与阅读有关，这是一个不同的主题。如果读取是您的痛点，那么您应该谈论的是RAM，而不是SSD，以及正确的索引和查询策略。

我的第一个建议是在不对两种配置进行负载测试的情况下，不对性能做任何假设。

从过去看过这样的配置（在纸上说得通），我的猜测是，将每个表放在单独的文件上不会对性能产生可衡量的积极影响……而额外的复杂性将抵消任何性能提升即使它们是可测量的。

最后，当要从Sql Server中压缩性能的每一个下降时，请参考以下图表（由Microsoft提供）：

从应用程序的角度可以进行的任何潜在优化都容易使硬件/数据库配置级别上的任何可能的优化都相形见...。因此，请适当关注您。

正如其他人所指出的，每个表一个文件并没有直接的好处。以下是史蒂夫·琼斯（Steve Jones）关于这个神话的起源的一个重要摘要：http : //www.sqlservercentral.com/blogs/steve_jones/2009/10/13/sql-server-legend-data-files-and-threads/

您可能还需要研究一个分区视图，我认为该视图受2008 Web Edition支持。针对分区视图进行编码有一些技巧，但是您可以相对轻松地模拟分区表的许多功能。

我认为每个表使用单独的文件不会带来性能上的好处。正确的索引可能会增加数据库服务器的性能（读取磁盘）。

SQL Server 2008 R2是否支持压缩？如果是，请打开它。

如果我错了纠正我。