当前，我正在开发一种产品，该产品使用MS SQL Server 2005进行相当密集的计算。在较高的层次上，我的产品的体系结构基于"运行"的概念，每次执行一些分析时，该产品都会存储在一系列产品中运行表(每次运行约100个表)。

我遇到的问题是，几个月后当运行次数增长到大约1000左右时，数据库的性能确实似乎下降了，特别简单的查询(例如检查表是否存在或者创建视图)可能会降低性能。最多需要一到两秒钟。

我听说使用多个文件组(这是我当前未做的事情)可能会有所帮助。这是真的吗？如果是这样，为什么/如何提供帮助？另外，如果还有其他建议，甚至是类似的建议，请使用较少的表，我欢迎他们。我只想加快数据库的速度，并希望将其置于可以扩展的状态。

解决方案

如果将它们放在逻辑驱动器而不是物理驱动器上，则可能会导致IO减慢的速度不那么快。

位于不同物理驱动器上的文件组将最大程度地提高性能，还可以拆分存放索引的位置，以使表写入和索引访问到达不同的磁盘。分区可以做很多事情，但是这个一般概念是速度影响最大的地方。

它可以帮助提高性能。将某些表/元素移动到磁盘的不同文件区域/部分。这可以在一定程度上减少影响数据库的外部碎片数量。

我还将查看其他因素(例如tracesql)以确定查询等为何变慢的原因，可能还有其他因素(例如查询统计信息，SP重新编译等)更容易修复，并且可以使我们获得更大的性能收益。

大约有1000个？单行写？多行交易？删除？

一般提示是将数据文件和日志文件放在单独的物理驱动器上。 SQL Server会跟踪对日志的每次写入，因此将这些写入不同的驱动器应该可以为我们带来总体上更好的性能。

但是SQL Server调优取决于应用程序的实际操作。有一些一般性提示，但我们必须自己衡量...

在性能方面，使用单独的文件/文件组的最大好处是它使我们可以将数据分布在多个物理磁盘上。这是有益的，因为使用多个磁盘可以同时处理多个数据请求(并行处理通常比串行处理要快)。在所有其他条件相同的情况下，这往往会提高性能，但是问题的多少取决于特定数据集和正在运行的查询。

根据描述，我们担心的缓慢操作是创建表并检查表是否存在。如果我们每次运行要生成100个表，那么在运行1000次后，我们将拥有100,000个表。我没有在单个数据库中创建那么多表的经验，但是我们可能会限制跟踪数据库架构的系统表的限制。在这种情况下，将表分散在多个数据库中可能会看到一些好处(这些数据库仍然可以全部存在于SQL Server的同一实例中)。

通常，SQL Profiler工具是查找慢查询的最佳起点。有数据列指示每个SQL批处理的CPU和IO成本，这将使我们指出最严重的问题。找到问题查询后，我将使用查询分析器为这些查询中的每一个生成查询计划，并查看是否可以知道是什么使它们变慢了。为此，请打开查询窗口，输入查询，然后按Ctrl + L。关于什么可能会变慢的完整讨论将填满整本书，但是要寻找的好东西是表扫描(对于大表来说非常慢)和低效的联接。

最后，我们可以仅通过重写查询就可以改善性能，或者我们可能必须对表架构进行更广泛的更改。例如，也许有一种方法每次运行只能创建一个或者几个表，而不是1000。有关特定设置的更多详细信息我们给出更详细的答案。

我还向该网站推荐很多有关如何使事情更快的提示：

http://www.sql-server-performance.com/

当我们谈到每次运行100个表时，我们实际上是在说要创建新的SQL表吗？如果是这样，我认为应用程序的体系结构可能是问题。我无法想象这样一种情况，我们将需要许多新表，而不是多次重用同一张表，而只需添加一两列就可以区分运行。

如果我们已经在重复使用同一组表，并且新运行仅意味着这些表中有其他行，那么问题可能就在于随着时间的推移新数据正在以几种方式之一损害性能。例如：

• 表/索引可能会在一段时间后分散。确保所有表都具有聚集索引。使用sys.DM_DB_INDEX_PHYSICAL_STATS检查是否有碎片，并在需要时使用REBUILD选项发出ALTER INDEX来对其进行碎片整理。
• 这些表可能太大了，因此在小表上的低效率现在在大表上显而易见。查看表上的适当索引以提高性能。
• SQL Server将缓存查询计划(尤其是存储过程)，但是如果表中的数据随着时间的推移发生显着变化，则该查询计划可能不再适用。查看sp_recompile中的存储过程，以查看是否需要此存储过程。

＃2是我在现实世界中最常看到的罪魁祸首。开发人员倾向于只使用少量测试数据进行开发，却忽略了正确的索引编制，因为我们可以使用20行的表执行几乎所有操作，而且看起来很快。

希望这可以帮助

将表拆分到单独的物理驱动器上。如果我们有那么多的磁盘IO，则需要一个不错的IO解决方案。突袭10号快速磁盘，将日志和数据库拆分到单独的驱动器上。

重新检查体系结构，我们可以使用多个数据库吗？如果我们一次创建1000个表，很快就会遇到一些我以前没有处理过的有趣的瓶颈。多个数据库应该解决这个问题。考虑让一个"控制"数据库包含所有主要元数据，然后让一个卫星数据库包含实际数据。

我们没有提到有关服务器的任何规格，但是当我们从8GB RAM变为20GB RAM时，我们看到了性能的显着提高。