相关疑难解决方法(0)

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

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

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

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

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

Microsoft Technet 文章建议将辅助文件组创建为默认文件组（请参阅下面的参考）。辅助文件组应该有多个文件，比如四个，每个文件都放在不同的磁盘上。作为同事的补充经验法则，文件数应等于 CPU 内核数。

我的理解是，这种设置非常适合机械旋转磁盘驱动器，因为旋转磁盘驱动器比固态驱动器慢得多，因此可以通过从多个磁头流式传输数据来提高性能。这种理解是否正确？

如果是，那么我的问题是基于成本的优化器是否考虑了较新的固态驱动器？当切换到新的固态驱动器时，旋转硬盘驱动器的性能瓶颈似乎消失了。我们的 IT 运营小组告诉我，虽然我目前被分配了一个虚拟驱动器，但数据实际上存储在 ISCSI SAN 上，它有多个固态驱动器。

这个问题旨在回答对于这种规模的大型数据库来说，最佳设置是什么：

1. 我应该有一个只有一个文件的默认辅助文件组吗？
2. 我是否应该有一个默认的辅助文件组，其中包含的文件数等于 CPU 上的内核数？
3. 使用固态驱动器时对数据库表进行分区是否可以提高性能？

我正在处理的当前项目需要一个可扩展的数据库，该数据库的大小将达到几 TB，用于存储大量日志数据。一周的样本大约有 1.5 亿条记录，我们需要存储 3 年的滚动日志。所以，我现在正在寻找长时间运行的查询来查找数据。我已经将索引调整到几乎所有工作都归因于非聚集索引搜索的程度；优化器不建议添加缺失的索引。

笔记

Microsoft SQL Server 上的许可目前由 CPU 内核决定。因此，在这个问题上投入更多内核是很敏感的，尤其是在这不会提高性能的情况下。

此外，我目前正在 SQL Server 2014 上进行开发，但将迁移到 SQL Server 2017 进行开发和生产。

更新 1

该项目将每晚加载日志，我预计很少（可能没有）更新或删除，因为日志根本不会改变 - 所以它们不会被重新加载。出于分析目的，将读取其他所有内容。

系统表的 PRIMARY 文件组，其中 SECONDARY 默认文件组用于其他所有内容。这样做的原因由本问题底部引用的链接解释。

将为表分区创建单独的文件组。数据库中还有其他足够小的表，它们将驻留在 SECONDARY 文件组中 - 我只对两个表进行分区，其中一个超过 1 亿条记录（按 IDENTITY 行号分区），另一个将进入数十亿条记录（按时间划分[每月]）。

我计划在 3 年内按月进行分区。因此，将有 36 个分区。我将为每年创建文件组，然后将 12 个文件放入相应的年度文件组中。分区策略是为了减少读取时间，因为会有大量数据扫描用于分析目的。年度文件组策略严格来说是为了便于 DBA 维护，他们可以通过删除单个文件组来删除一年的数据。

参考：

SQL Server 最佳实践设置默认文件组