目前，我正在开发一种产品，该产品使用 MS SQL Server 2005 进行相当密集的计算。在高层次上，我的产品架构基于“运行”的概念，每次我进行一些分析时，它都会被存储起来在一系列运行表中（每次运行约 100 个表）。
我遇到的问题是，当运行数在几个月后增长到大约 1,000 次左右时，数据库的性能似乎真的下降了，特别是简单的查询，例如检查表是否存在或创建视图最多可能需要一到两秒。
我听说使用多个文件组（我目前没有这样做）会有所帮助。这是真的吗，如果是这样，为什么/如何帮助？此外，如果有其他建议，即使是使用更少表格的建议，我也愿意接受。我只是想加快数据库的速度，并希望让它处于可扩展的状态。
【问题讨论】：
标签： sql-server
在性能方面，使用单独的文件/文件组的最大好处是它可以让您将数据分布在多个物理磁盘上。这是有益的，因为使用多个磁盘，可以同时处理多个数据请求（并行通常比串行更快）。在所有其他条件相同的情况下，这往往会提高性能，但多少取决于您的特定数据集和您正在运行的查询。
根据您的描述，您担心的缓慢操作是创建表和检查表是否存在。如果您每次运行生成 100 个表，那么在 1000 次运行之后您将拥有 100,000 个表。我没有太多在单个数据库中创建这么多表的经验，但您可能会遇到跟踪数据库模式的系统表的限制。在这种情况下，通过将表分布在多个数据库中（这些数据库仍然可以都存在于同一个 SQL Server 实例中），您可能会看到一些好处。
一般来说，SQL Profiler 工具是查找慢查询的最佳起点。有数据列指示每个 SQL 批处理的 CPU 和 IO 成本，它们应该指出最严重的违规者。一旦你找到了问题查询，我会使用查询分析器为每个查询生成查询计划，看看你是否能分辨出是什么让它们变慢。通过打开查询窗口、输入查询并按 Ctrl+L 来执行此操作。完整的讨论可能会很慢会写满整本书，但值得关注的是表扫描（对于大表来说非常慢）和低效的连接。
最后，您可能只需重写查询即可改进，或者您可能必须对表架构进行更广泛的更改。例如，也许有一种方法可以每次运行只创建一个或几个表，而不是 1000 个。有关您的特定设置的更多细节将有助于我们给出更详细的答案。
我还推荐这个网站，以获取有关如何加快速度的许多提示：
【讨论】：
当您谈到每次运行 100 个表时，您的意思是真的要创建新的 SQL 表吗？如果是这样，我认为您的应用程序的体系结构可能是问题所在。我无法想象你需要那么多新表而不是多次重复使用相同的几个表并简单地添加一两列来区分运行的情况。
如果您已经在重复使用同一组表并且新的运行只是意味着这些表中的额外行，那么问题可能只是随着时间的推移新数据会以多种方式损害性能。例如：
#2 是我在现实世界中最常看到的罪魁祸首。开发人员倾向于仅使用一小部分测试数据进行开发，而忽略了正确的索引，因为您几乎可以对 20 行的表执行任何操作，而且它看起来很快。
希望对你有帮助
【讨论】：
大约 1000 个什么？单行写入？多行事务？删除？
一般提示是将数据文件和日志文件放在不同的物理驱动器上。 SQL Server 会跟踪对日志的每次写入，因此将它们放在不同的驱动器中应该会给您带来更好的性能。
但 SQL Server 调优取决于应用程序实际执行的操作。有一般的提示，但你必须衡量你自己的东西......
【讨论】：
位于不同物理驱动器上的文件组将为您带来最大的性能提升，还可以拆分索引所在的位置，以便表写入和索引访问访问不同的磁盘。分区可以做很多事情，但这个一般概念是对速度影响最大的地方。
【讨论】：
它可以帮助提高性能。将某些表/元素移动到磁盘的不同文件区域/部分。这可以在一定程度上减少影响数据库的外部碎片量。
我还会查看其他因素（例如 tracesql）以确定查询等速度变慢的原因 - 可能还有其他因素（例如查询统计信息、SP 重新编译等）更容易修复并且可以为您带来更大的性能提升。
【讨论】：
在不同的物理驱动器上拆分表。如果你有这么多磁盘 IO，你需要一个不错的 IO 解决方案。 Raid 10，快速磁盘，将日志和 DB 拆分到单独的驱动器上。
重新检查您的架构 - 您可以使用多个数据库吗？如果您一次创建 1000 个表，您很快就会遇到一些我以前没有处理过的有趣瓶颈。多个数据库应该可以解决这个问题。考虑拥有一个包含所有主要元数据的“控制”数据库，然后是包含实际数据的卫星数据库。
您没有提及您的服务器的任何规格 - 但是当我们从 8GB 到 20GB RAM 时，我们看到了性能的显着提升。
【讨论】：
如果您将它们放置在单独的驱动器上 - 不是逻辑驱动器而是物理驱动器，这样 IO 就不会拖慢您的速度。
【讨论】：