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

Question

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

保持这么多列的任何缺点。

我也有保留这些多列，

我怎样才能提高性能 - 比如使用SP的，指数？

Answer 1

宽桌子没有什么固有的错误。规范化的主要情况是数据库大小，大量空列占用大量空间。

Answer 2

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

这只是一个事实。这并不是说你没有理由拥有许多专栏。上面的内容并没有给我们一个单一的理由，把一个实体的表格与许多列拆分成多个表格，列数更少。这种解决方案的管理开销很可能超过任何感知的性能收益。

根据我对异常宽表（批量导入数据的非规范化架构）的经验，我建议给你的第一个建议是尽量减少列数。我必须处理大量疯狂的数据，并将大多数列保留为VARCHAR（255）。我建议不要这样。虽然便于开发，但性能会失去控制，特别是在使用Perl时。将列缩小到最小值（例如VARCHAR（18））非常有帮助。

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

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

Answer 3

在表中有很多列的问题是使用集群主键查找行可能很昂贵。如果可以更改模式，将其分解为许多标准化表格将是提高效率的最佳途径。我强烈推荐这门课程。

如果不是，那么您可能可以使用索引来加快一些SELECT查询的速度。如果您的查询仅使用少量列，则在这些列上添加索引可能意味着不需要扫描聚集索引。当然，就存储空间和INSERT，UPDATE和DELTETE时间而言，索引总是要付出代价的，所以这可能不适合你。

Answer 4

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

在Universal Data Models的家伙将有一些好的想法重构你的表。 Red Gate的SQL Refactor使分割表更容易。