Question

问题1：表格中我们可以拥有的最大列数是多少

问题2：表中应该具有的最大列数是多少

Answer 1

答案1：可能比你拥有的多，但不会超过你的成长。

答案2：比你少。

提出这些问题通常表明您没有很好地设计表格。您可能正在练习元数据Tribbles 反模式。这些列往往会随着时间的推移而累积，创建一组无限的列，这些列基本上存储相同类型的数据。例如。 subtotal1，subtotal2，subtotal3等

相反，我猜你应该创建一个额外的依赖表，所以你的很多列会变成很多行。这是设计适当的规范化数据库的一部分。

CREATE TABLE Subtotals (
  entity_id    INT NOT NULL,
  year_quarter SMALLINT NOT NULL, -- e.g. 20094
  subtotal NUMERIC(9,2) NOT NULL,
  PRIMARY KEY (entity_id, year_quarter),
  FOREIGN KEY (entity_id) REFERENCES Entities (entity_id)
);

我的前同事也写过一篇关于此的博客：

Understanding the maximum number of columns in a MySQL table

答案并不像你想象的那么简单。

Answer 2

SQL 2000：1024

SQL 2005：1024

SQL 2008：1024用于非宽表，30k用于宽表。

宽表用于在SQL 2008中使用新的稀疏列功能时，该功能是为大量通常为空的列而设计的。

仅仅因为这些限制是可用的，并不意味着您应该使用它们，但是，我将从根据要求设计表开始，然后检查是否需要将1个表垂直分区为2个较小的表等。< / p>

Answer 3

1） http://msdn.microsoft.com/en-us/library/aa933149%28SQL.80%29.aspx

1024似乎是极限。

2）远不到1024 :)。说真的，这取决于你想要数据库的规范化程度。通常，表中的列越少，人们就越容易理解（通常）。与人员表一样，您可能希望将人员的地址存储在另一个表中（例如，person_address）。最好将您的数据分解为对您的业务模型有意义的实体，并从那里开始。

Answer 4

2）那里有很多指导方针。特别是关于数据库规范化。总体原则始终是能够适应的。与类类似，具有大量列的表不是非常灵活。你应该问自己的一些问题：

A列是否描述了可以/应该与B列分组的对象（表）的属性
数据更新。请记住，大多数RDBMS在更新值时都会执行行锁定。这意味着如果您不断更新A列而另一个进程正在更新B列，那么他们将争夺该行，这将产生争用。

数据库设计不仅仅是一门科学。虽然指南和技术限制将使您朝着正确的方向前进，但没有硬性规则可以使您的系统100％运行或失败。

Answer 5

我认为4096在mysql中，SQL Server我不知道
几个月前我在一个特殊场景中问the same question，也许这些答案可以帮助你做出决定。通常，我会说尽可能少。

表中的最大列数

5 个答案: