具有大量表的 SQL Server 数据库答案

【问题标题】：SQL Server database with MASSIVE amount of tables具有大量表的 SQL Server 数据库
【发布时间】：2009-03-31 14:51:04
【问题描述】：

有人要求我解决 SQL Server 2005 数据库中的性能问题。

挑战不是海量数据，而是海量表。单个数据库中有 30,000 多个表。总数据大小约为 650 GB。

我无法控制创建所有这些表的应用程序。该应用程序在拥有 10-15 个部门的大公司中每个“部门”使用大约 2,500 个表。

您如何开始检查性能问题？您在 VLDB (Very Large DB) 上找到的所有文章都是关于数据量的，而不是表的数量。

有什么想法吗？指针？提示？

【问题讨论】：

【解决方案1】：

像任何其他类型的性能调整一样开始。除其他事项外，您不应假设大量表构成性能问题。这可能是一个红鲱鱼。

相反，问用户“什么是慢”？即使您测量了性能（也许使用 Profiler），您的数字也可能与感知到的性能问题不匹配。

【讨论】：

完全同意。用户甚至可能不会注意到任何缓慢，因此您可能无需执行任何操作。
是的 - 纯粹的数字可能甚至不是真正的问题。
事实上，剪切数可能根本不是问题，除非我们这些对糟糕的数据库设计感到疑惑的人除外。可能该模式会赶走优秀的数据库开发人员，导致数据库随着时间的推移变得越来越差。 ;-)

【解决方案2】：

正如其他人所指出的，桌子的数量可能表明设计不佳，但它远非扣篮，它是性能问题的根源。

对于任何性能优化，我能给您的最佳建议是停止猜测问题的根源并去寻找它。最重要的是，在确定问题的根源之前不要开始优化。

我会首先在数据库上运行一些跟踪并找出性能不佳的查询。这也将告诉您应用程序最常使用哪些表。很可能大量这些表可能是：A）剩余的临时表； B) 不再使用；或 C) 没有人清理的工作台。

【讨论】：

【解决方案3】：

抛开糟糕的数据库设计，如果没有用户报告响应时间很慢，那么您目前没有性能问题。

如果您确实遇到性能问题：

1）检查碎片（dbcc showcontig）

2) 检查硬件规格、RAID/驱动器/文件位置。检查 SQL 服务器错误日志。如果硬件似乎未指定或设计不佳，请运行性能计数器（请参阅 PAL 工具）

3) 在正常查询工作负载期间收集跟踪数据并识别昂贵的查询（请参阅此 SO 答案：How Can I Log and Find the Most Expensive Queries?）

【讨论】：

【解决方案4】：

软件是否创建了所有这些表？如果是这样，也许相同的错误会一遍又一遍地重复。所有表都有主键吗？它们都有聚集索引吗？是否存在所有必要的非聚集索引（那些用于过滤和连接的列）等等等等。

是否可以选择升级 SQL Server 2008？如果是这样，您可以利用新的 Policy Based Management 功能来为大量表实施最佳实践。

现在开始调优，我会使用分析器找到那些持续时间最长的语句，然后看看你可以做些什么来改进它们（添加索引通常是最简单的方法）。

【讨论】：