除了数据总量的增加之外，表中是否有大量列的性能成本？如果是这样，将表拆分成几个较小的表可以帮助解决这个问题吗？
答案 0 :(得分：16)
如果你真的需要所有这些专栏（也就是说，这不仅仅表明你有一个设计糟糕的表格），那么一定要保留它们。
只要你
，这不是性能问题如果您有30列甚至200列，那么数据库就没问题了。如果你想一次检索所有这些列，你只是让它更难工作。
但是有很多列是一个糟糕的代码气味;我想不出任何合理的理由，设计良好的表会有这么多列，而你可能需要与其他更简单的表格建立一对多的关系。
答案 1 :(得分：14)
我不同意所有这些帖子说30列气味像坏代码。如果您从未使用过具有30多个合法属性的实体的系统，那么您可能没有太多经验。
HLGEM提供的答案实际上是最好的答案之一。我特别喜欢他的问题“是否有自然分裂......经常使用与不经常使用”是一个非常好的问题要问自己，你可能能够以自然的方式打破桌面（如果事情得到解决的话）失控）。
我的意见是，如果您的表现目前可以接受，除非您需要，否则不要重新发明解决方案。
答案 2 :(得分：13)
即使你已经选择了一个答案，我也要考虑到这一点。是的表太宽可能会导致性能问题（以及数据问题），应该分成具有一对一关系的表。这是由于数据库如何存储数据（至少在SQL Server中不确定mySQl，但值得在文档中读取数据库如何存储和访问数据）。
三十列可能太宽而且可能没有，这取决于列的宽度。如果将30列将占用的总字节数加起来，它是否宽于可以存储在记录中的最大字节数？
您需要的其中一些列是否比其他列更少（换句话说，在必需和常用信息之间存在自然区分，而其他信息可能只出现在一个地方而不是其他地方），然后考虑拆分桌子。
如果您的某些列是phone1，phone2，phone3之类的内容 - 那么您需要多少列并不需要具有一对多关系的相关表格。
一般情况下，虽然30列不是很大，但可能没问题。
答案 3 :(得分：7)
从技术上讲，30列绝对没问题。但是，具有许多列的表通常表明您的数据库未正确规范化，即它可能包含冗余和/或不一致的数据。
答案 4 :(得分：3)
应该没问题，除非你到处都有select * from yourHugeTable。始终只选择您需要的列。
答案 5 :(得分：3)
通常不会将30列视为过多的数字。
另一方面，答案 6 :(得分：2)
除了性能之外，DataBase规范化还需要具有太多表和关系的数据库。规范化使您可以轻松访问模型和灵活的关系，以执行不同的SQL查询。
As it is shown in here，有八种形式的规范化。但是对于许多系统来说，应用第一，第二和第三范式是足够的。
因此，不是选择相关列并编写长sql查询，而是一个好的规范化数据库表会更好。
答案 7 :(得分：2)
例如，对于“人物”表中的列“名称”，“性别”，“年龄”，“生物”以及多达100列甚至更多列，为了最大限度地提高性能，最好将它们定义为：
我们的想法是尽可能将列定义为小并在固定长度中定义。动态列应该在表结构的末尾，因此固定长度列在它们之前是ALL。
不言而喻，这会导致大量行浪费大量磁盘存储，但正如您想要的性能，我猜这将是成本。
另外一个提示就是你会发现更频繁使用（选择或更新）的列比其他列更强，你应该将分隔到另一个表中与包含不常使用的列的另一个表形成一对一关系，并使用较少的列执行查询。
答案 8 :(得分：1)
用法明智，在某些情况下是合适的，例如，表中的多个应用程序共享某些列而不是其他列，并且报告需要为所有列提供实时单个数据池，而不进行数据转换。如果一个200列表能够提供分析能力和灵活性，那么我会说“走多远”。当然，在大多数情况下，标准化提供了效率并且是最佳实践，但是做适合您需要的方法。