哪个效率更高：多个MySQL表还是一个大表？

我在MySQL数据库中存储了各种用户详细信息。最初，它是在各种表中设置的，这意味着数据与UserId链接，并通过有时复杂的调用输出，以根据需要显示和操作数据。设置一个新系统，将所有这些表组合成一个大的相关内容表几乎是有意义的。

• 这将是帮助还是阻碍？
• 调用，更新或搜索/操作时的速度考虑？

这是我的一些表结构的示例：

• 用户-用户ID，用户名，电子邮件，加密的密码，注册日期，IP
• user_details-Cookie数据，姓名，地址，联系方式，从属关系，人口统计数据
• user_activity-贡献，最近一次在线访问，最后一次查看
• user_settings-配置文件显示设置
• user_interests-广告可定位变量
• user_levels-访问权限
• user_stats-匹配数

编辑：到目前为止，我已经对所有答案进行了投票，它们都有本质上可以回答我问题的元素。

大多数表具有1：1的关系，这是使它们归一化的主要原因。

如果表格跨越100多个列，而这些单元格的大部分可能仍为空时，会不会有问题？

多个表以下列方式/案例提供帮助：

（a）如果不同的人要开发涉及不同表的应用程序，则将它们拆分是有意义的。

（b）如果您想为不同的人赋予不同的权限，以进行数据收集的不同部分，则将它们拆分会更方便。（当然，您可以查看定义视图并对其进行适当授权）。

（c）对于将数据移动到不同的地方，尤其是在开发过程中，使用表来减小文件大小可能是有意义的。

（d）当您在单个实体的特定数据收集上开发应用程序时，较小的占地面积可能会给您带来舒适感。

（e）这是一种可能性：您认为作为单个值的数据将来可能会变成真正的多个值。例如，信用额度到目前为止是单个值字段。但是明天，您可能会决定将值更改为（日期，日期至信用值）。拆分表现在可能会派上用场。

我的投票将是针对多个表-数据已适当拆分。

祝好运。

合并表称为非规范化。

可能会（也可能不会）帮助使某些查询（使很多JOINs）更快地运行，而以创建维护地狱为代价。

MySQL只能使用JOIN方法，即NESTED LOOPS。

这意味着对于驱动表中的每个记录，MySQL在循环中在驱动表中找到匹配的记录。

查找记录是相当昂贵的操作，可能需要花费纯记录扫描数十倍的时间。

将所有记录移到一个表中将帮助您摆脱此操作，但是表本身会变大，并且表扫描需要更长的时间。

如果其他表中有很多记录，则表扫描的增加可能会增加按顺序扫描记录的好处。

另一方面，可以保证维护。

他们都是1：1的关系吗？我的意思是，如果某个用户可能属于不同的用户级别，或者如果用户兴趣在用户兴趣表中表示为多个记录，那么合并这些表将立即成为问题。

关于以前关于规范化的答案，必须说数据库规范化规则完全忽略了性能，只看什么是整洁的数据库设计。这通常是您想要实现的目标，但是有时为了追求性能而积极地规范化是有意义的。

总而言之，我要说的问题归结为表中有多少个字段以及访问它们的频率。如果用户活动通常不是很有趣，那么出于性能和维护的原因，始终将其保留在同一记录上可能会很麻烦。如果经常访问某些数据（例如设置），但仅包含太多字段，则合并表可能也不方便。如果仅对性能提高感兴趣，则可以考虑其他方法，例如将设置分开，但将其保存在自己的会话变量中，这样就不必经常查询数据库。

难道所有这些表都一个1-to-1关系？例如，将每个用户的行只需要在一个相应行user_stats或user_levels？如果是这样，将它们组合到一个表中可能很有意义。如果不是 这种关系1 to 1，则将它们组合（去规范化）可能没有意义。

将它们放在单独的表中而不是一个表中可能对性能几乎没有影响，除非您有成千上万的用户记录。您将获得的唯一真正收获是通过组合查询来简化查询。

预计到达时间：

如果您的关注是关于有太多的列，然后想想什么东西，你通常使用起来并结合这些，（如果需要的话或几个单独的表），留下其余的在一个单独的表。

如果您查看数据的使用方式，我的猜测是，您会发现大约80％的查询使用20％的数据，而其余80％的数据仅偶尔使用。将经常使用的20％合并到一个表中，然后将不经常使用的80％留在单独的表中，您可能会做出很大的妥协。

创建一个大表违反了关系数据库的原则。我不会将所有这些组合到一张桌子中。您将获得多个重复数据实例。例如，如果您的用户有三个兴趣，则您将有3行，其中相同的用户数据仅用于存储三个不同的兴趣。肯定要使用多个“标准化”表方法。见这对数据库标准化Wiki页面。

编辑： 我已经更新了我的答案，因为您已经更新了您的问题...从现在开始，我现在甚至更多地同意我的最初答案。

这些单元格的很大一部分可能仍为空

例如，如果某个用户没有任何兴趣，那么如果您进行归一化，那么您就不会在该用户的兴趣表中出现一行。如果您将所有内容都放在一个庞大的表中，那么您将拥有仅包含NULL的列（显然有很多列）。

我曾在一家电话公司工作，那里有大量的表格，要获取数据可能需要很多联接。当从这些表中读取数据的性能至关重要时，则创建可以生成平面表（即非规范化表）的程序，该程序将不需要连接，计算等报告即可指向。然后将这些与SQL Server代理结合使用，以一定的时间间隔运行该作业（即每周一次查看某些统计信息，每周运行一次，依此类推）。

为什么不使用相同的方法，Wordpress通过让一个用户表具有每个人都拥有的基本用户信息，然后添加一个“ user_meta”表，该表基本上可以是与用户ID相关联的任何键，值对。因此，如果您需要查找用户的所有元信息，则可以将其添加到查询中。如果不需要诸如登录之类的东西，您也不必总是添加额外的查询。这种方法的好处还使您的表可以向用户添加新功能，例如存储其Twitter句柄或每个个人兴趣。您也不必处理关联ID的迷宫，因为您有一个可以管理所有元数据的表，并且将其限制为仅一个关联而不是50个关联。

Wordpress专门这样做是为了允许通过插件添加功能，因此允许您的项目更具可伸缩性，并且如果您需要添加新功能，则不需要彻底的数据库检查。

我认为这是“取决于情况”的情况之一。拥有多个表更干净，理论上可能更好。但是，当您必须联接6-7个表以获取有关单个用户的信息时，您可能会开始重新考虑这种方法。

我要说的是，这取决于其他表格的真正含义。user_details是否包含多于1个/用户，依此类推。标准化的哪个级别最适合您的需求取决于您的需求。

如果您的一张表的索引很好，那可能会更快。但是另一方面，维护起来可能更加困难。

在我看来，您可以跳过User_Details，因为它可能与Users是一对一的关系。但是其余的每个用户可能有很多行？