sql-server - 在 MS SQL Server 中管理大量表的最佳方法是什么？

Question

这个问题与另一个问题相关:
Will having multiple filegroups help speed up my database?

我们正在开发的软件是一个使用MS SQL Server 2005来存储关系数据的分析工具。初始分析可能会很慢(因为我们正在处理数百万或数十亿行数据)，但是快速调用以前的分析有性能要求，因此我们“保存”每次分析的结果。

我们当前的方法是将分析结果保存在一系列“特定于运行”的表中，并且分析非常复杂，每次分析最终可能会包含多达 100 个表。通常，这些表每次分析会占用几百 MB(与我们数百 GB、有时甚至数 TB 的源数据相比，这很小)。但总的来说，磁盘空间对我们来说不是问题。每组表都特定于一个分析，在许多情况下，与引用源数据相比，这为我们提供了巨大的性能改进。

一旦我们积累了足够多的保存分析结果，这种方法就开始失效——在我们添加更强大的存档/清理功能之前，我们的测试数据库已攀升至数个百万表。但即使是在生产中，我们拥有超过 100,000 张 table 也不是一件容易的事。 Microsoft 对 sysobjects 的大小设置了相当大的理论限制(约 20 亿)，但是一旦我们的数据库增长到超过 100,000 个左右，像 CREATE TABLE 和 DROP TABLE 这样的简单查询就会显着减慢速度。

我们有一些空间来讨论我们的方法，但我认为如果没有更多上下文，这可能很难做到，所以我想更普遍地提出这个问题:如果我们被迫创建这么多表，什么是最好的管理它们的方法？多个文件组？多个模式/所有者？多个数据库？

另一个说明:我对“简单地用硬件来解决问题”(即添加 RAM、CPU 功率、磁盘速度)的想法并不感到兴奋。但我们也不排除这种可能性，特别是如果(例如)有人可以明确地告诉我们添加 RAM 或使用多个文件组会对管理大型系统目录产生什么影响。

Answer 1

在没有首先看到整个系统的情况下，我的第一个建议是将历史运行保存在组合表中，并将 RunID 作为键的一部分 - 维度模型也可能与这里相关。可以对该表进行分区以进行改进，这还允许您将该表分散到其他文件组中。

另一种可能性是将每次运行放入自己的数据库中，然后分离它们，仅根据需要附加它们(并且以只读形式)

CREATE TABLE 和 DROP TABLE 可能表现不佳，因为主数据库或模型数据库未针对此类行为进行优化。

我还建议与 Microsoft 讨论您选择的数据库设计。