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