我被要求解决SQL Server 2005数据库中的性能问题。
挑战不是大量的数据，而是大量的数据表。一个数据库中有超过30,000个表。总数据大小约为650 GB。
我无法控制创建所有这些表的应用程序。该应用程序在一个大型公司中使用大约2,500个表，每个“分部”，10-15个分区。
您如何开始检查性能问题？您在VLDB（超大型数据库）上找到的所有文章都是关于数据量，而不是表格数量。
有什么想法吗？指针？提示？
答案 0 :(得分：5)
像任何其他类型的性能调整一样开始。除此之外，您不应该假设大量的表构成了性能问题。它可能是一个红鲱鱼。
相反，问用户“什么慢”？即使您测量了性能（也许使用Profiler），您的数字可能与感知到的性能问题不匹配。
答案 1 :(得分：2)
正如其他人所指出的那样，表的数量可能表明设计不好，但它远不是一个扣篮，它是性能问题的根源。
我可以为您提供任何性能优化的最佳建议是停止猜测问题的根源并继续寻找它。最重要的是，在您确定问题的根源之前，不会开始优化。
我从在数据库上运行一些跟踪开始，并确定性能不佳的查询。这也可以告诉您应用程序最常使用哪些表。很可能大量的这些表可能是：A）剩余临时表; B）不再使用;或者C）工作台有人没有清理。
答案 2 :(得分：0)
将糟糕的数据库设计放在一边，如果没有用户报告响应时间较慢，那么当前就会出现性能问题。
如果您遇到性能问题：
1）检查碎片（dbcc showcontig）
2）检查硬件规格，RAID /驱动器/文件放置。检查SQL Server错误日志。 如果硬件似乎未指定或设计不合理，请运行性能计数器（请参阅PAL 工具）
3）在正常查询工作负载期间收集跟踪数据并识别昂贵的查询（请参阅此SO答案：How Can I Log and Find the Most Expensive Queries?）
答案 3 :(得分：-1)
软件是否创建了所有这些表？如果是这样，也许一遍又一遍地重复相同的错误。所有表都有主键吗？他们都有聚集索引吗？是否存在所有必需的非聚集索引（那些用于过滤和连接的列）等等。
升级SQL Server 2008是一个选项吗？如果是这样，您可以利用新的Policy Based Management功能为大量表格强制执行最佳做法。
要立即开始调整，我会使用探查器查找持续时间最长的语句，然后看看你可以做些什么来改进它们（添加索引通常是最简单的方法）。