如果表中的列太多，性能是否会降低？

从技术上讲，30列绝对没问题。但是，具有许多列的表通常表明您的数据库未正确规范化，也就是说，它可能包含冗余和/或不一致的数据。

如果你真的需要所有这些列（也就是说，这不仅仅是一个迹象，表明你的表设计得很差），那么一定要保留它们。

这不是性能问题，只要你

• 对需要用于选择行的列使用适当的索引
• 不要在 SELECT 操作中检索不需要的列

如果您有 30 列甚至 200 列，则对数据库没有问题。如果你想一次检索所有这些列，你只是让它工作得更困难一些。

但是有很多列是一种不好的代码气味;我想不出任何合理的理由，一个精心设计的表会有这么多列，而你可能需要与其他一些更简单的表建立一对多关系。

应该没问题，除非你到处都是。始终只选择您需要的列。select * from yourHugeTable

除了性能之外，数据库规范化还需要具有太多表和关系的数据库。通过规范化，您可以轻松访问模型和灵活的关系，以执行不同的 sql 查询。

如图所示，有八种形式的归一化。但对于许多系统来说，应用第一、第二和第三范式就足够了。

因此，与其选择相关列和编写长 sql 查询，不如使用好的规范化数据库表。

30 列通常不会被视为过多的数字。

另一方面，三千列......您将如何实现一个非常宽的“表”？

即使你已经选择了答案，我也会对此进行权衡。是的，太宽的表可能会导致性能问题（以及数据问题），应将其分隔为具有一对一关系的表。这是由于数据库如何存储数据（至少在SQL Server中不确定MySQL，但值得阅读有关数据库如何存储和访问数据的文档）。

三十列可能太宽，也可能没有，这取决于列的宽度。如果将 30 列将占用的总字节数相加，它是否比记录中可以存储的最大字节数宽？

某些列是否比其他列更不经常需要（换句话说，在必需和经常使用的信息以及其他可能只出现在一个地方而不是其他地方的东西之间是否存在自然的分裂），然后考虑拆分表格。

如果你的某些列是 phone1、phone2、phone3 之类的东西，那么无论你有多少列，你都需要一个具有一对多关系的相关表。

一般来说，虽然 30 列不是特别大，而且可能没问题。

我不同意所有这些帖子，说 30 列闻起来像糟糕的代码。如果您从未在具有 30+ 合法属性的实体的系统上工作过，那么您可能没有太多经验。

HLGEM提供的答案实际上是最好的答案。我特别喜欢他的问题“是否存在自然分裂......经常使用与不经常使用“是问自己的非常好的问题，你也许可以以一种自然的方式打破桌子（如果事情失控）。

我的评论是，如果你的表现目前是可以接受的，除非你需要它，否则不要寻求重新发明一个解决方案。

30 对我来说似乎并不多。除了必要的索引和适当的 SELECT 查询之外，对于宽表，还有 2 个基本提示：

1. 将列定义得尽可能小。
2. 当每个表有大量列时，请尽可能避免使用动态列，例如 VARCHAR 或 TEXT。请尝试使用固定长度的列，例如 CHAR。这是为了牺牲磁盘存储来换取性能。

例如，对于“person”表中具有多达 100 列甚至更多列的“name”、“gender”、“age”、“bio”列，为了最大限度地提高性能，最好将它们定义为：

1. 名称 - 字符（70）
2. 性别 - TINYINT（1）
3. 年龄 - TINYINT（2）
4. bio - 文本

这个想法是在合理可能的情况下以尽可能小的长度定义列。动态列应位于表结构的末尾，因此固定长度的列都位于它们之前。

不言而喻，这将引入大量行浪费的大量磁盘存储，但正如您想要性能一样，我想这将是成本。

另一个提示是，随着您的进行，您会发现比其他列更频繁地使用（选择或更新），您应该将它们分隔到另一个表中，以形成与包含不常用列的另一个表的一对一关系，并使用较少的列执行查询。

在用法方面，它适用于某些情况，例如，表为多个应用程序提供服务，这些应用程序共享某些列但不共享其他列，并且报告需要为所有数据提供实时的单个数据池，而无需数据转换。如果一个 200 列表表能够实现这种分析能力和灵活性，那么我会说“做多”。当然，在大多数情况下，规范化可以提高效率，并且是最佳实践，但请根据您的需要做有效的事情。