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

Question

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

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

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

每个表使用一个文件实际上会最大限度地提高性能，还是我忽略了会使这样做变得多余的内置 SQL Server 引擎特性？

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

Answer 1

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

你到底在说什么？不确定您从哪里获得信息，但您当然应该丢弃该来源。您在这里假设的任何内容实际上都不正确。

如果您想阅读有关 SQL Server SSD 性能的精彩讨论，这里有几个博客系列。像往常一样，保罗兰德尔的一个是最重要的读物：

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

Brent 也有一个关于该主题的精彩演讲：SSD上的SQL：Hot and Crazy Love以及其他更多内容。

通过所有这些演示，您会很快注意到它们都专注于写入，因为这是 SSD 性能发挥作用的地方。你的帖子措辞几乎完全是关于阅读，这是一个不同的话题。如果读取是您的痛点，那么您应该谈论 RAM，而不是 SSD，以及适当的索引和查询策略。

Answer 2

我的第一个建议是，如果不对两种配置进行负载测试，就不要对性能做出任何假设。

我在过去看到这样的配置（在纸上有意义）的猜测是，将每个表放在一个单独的文件中不会对性能产生可衡量的积极影响......并且额外的复杂性将抵消任何性能提升即使它们是可衡量的。

最后，当谈到从 Sql Server 中榨取每一滴性能时，我向您推荐以下图表（提供我的 Microsoft）：

任何可以从应用程序角度进行的潜在优化都很容易使硬件/数据库配置级别的任何可能优化相形见绌……所以要适当地集中注意力。