表设计和性能与数据库有关？

Question

我在SQL Server 2005中有一个包含158列的表。

保留这么多专栏的任何不利之处。

此外，我必须保留那么多列，

如何提高性能 - 比如使用SP，索引？

Answer 1

宽表没有任何内在错误。规范化的主要情况是数据库大小，其中许多空列占用大量空间。

Answer 2

当您通常需要特定行的所有字段时，宽表可以非常高效。您是否跟踪过用户的使用模式？如果他们通常只从多行中拉出一两个字段，那么你的表现就会受到影响。主要问题是当您的总行数达到8k页标记时。这意味着SQL必须为每一行（第一页+溢出页面）两次击中磁盘，并且不计算任何索引命中。

Universal Data Models的家伙会有一些很好的想法来重构你的桌子。而Red Gate的SQL Refactor使得分割表堆更容易。

Answer 3

您拥有的列越多，查询就越慢。

这只是一个事实。这并不是说你有很多专栏没有理由。上面没有给出一个全权委托将一个实体的具有多列的表的值分成具有较少列的多个表。这种解决方案的管理开销很可能超过任何感知到的性能提升。

根据我对异常宽表（批量导入数据的非规范化模式）的经验，我给你的第一个建议是尽可能保持列的精简。我不得不处理大量疯狂数据，并将大部分列保留为VARCHAR（255）。我建议不要这样做。虽然便于开发，但性能会失控，尤其是在使用Perl时。将列缩小到最小值（例如VARCHAR（18））有很大帮助。

存储过程只是批量的SQL命令;他们没有任何直接的速度，除了经常使用某些类型的存储过程最终将使用缓存的查询计划（这是一个性能提升）。

您可以使用索引来加速某些查询，但这里没有严格的规则。良好的索引设计完全取决于您运行的查询类型。根据定义，索引将使您的写入速度变慢;它们的存在只是为了让你的阅读更快。

Answer 4

在表中包含许多列的问题是使用群集主键查找行可能很昂贵。如果可以更改架构，将其分解为许多规范化表将是提高效率的最佳方法。我强烈推荐这门课程。

如果没有，那么您可以使用索引来更快地进行一些SELECT查询。如果您的查询仅使用少量列，则在这些列上添加索引可能意味着不需要扫描聚簇索引。当然，就存储空间和INSERT，UPDATE和DELTETE时间而言，索引总是要付出代价，所以这对你来说可能不是一个好主意。