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