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

Question

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

• 这会成为一种帮助还是障碍？
• 调用，更新或搜索/操作时的速度考虑因素？

以下是我的一些表结构的示例：

• 用户 - UserId，用户名，电子邮件，加密密码，注册日期，ip
• user_details - Cookie数据，姓名，地址，联系方式，从属关系，人口统计数据
• user_activity - 捐款，上次在线，上次观看
• user_settings - 个人资料显示设置
• user_interests - 广告可定位变量
• user_levels - 访问权限
• user_stats - hits，tallies

---

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

大多数表格具有1：1的关系，这是使它们非规范化的主要原因。

当这些表格的大部分可能保持空白时，如果表格跨越100多列，是否会出现问题？

Answer 1

多个表有以下方式/案例帮助：

（a）如果不同的人正在开发涉及不同表格的应用程序，那么拆分它们是有意义的。

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

（c）为了将数据移动到不同的地方，特别是在开发过程中，使用表格来缩小文件大小可能是有意义的。

（d）在为单个实体的特定数据收集开发应用程序时，较小的足迹可能会让您感到舒适。

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

我的投票将针对多个表格 - 数据被适当地分割。

祝你好运。

Answer 2

组合表称为非正规化。

它可能（或可能不）帮助进行一些查询（这会使很多JOIN s）运行得更快，但代价是创建维护地狱。

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

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

查找记录是一项非常昂贵的操作，可能需要几倍于纯记录扫描的时间。

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

如果您在其他表中有大量记录，那么表扫描的增加可能会使按顺序扫描的记录的权益超重。

另一方面，维护地狱是有保障的。

Answer 3

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

关于规范化的先前答案，必须说数据库规范化规则完全忽视了性能，并且只关注什么是整洁的数据库设计。这通常是你想要实现的目标，但有时候为了追求绩效而积极地反规范化是有意义的。

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

Answer 4

这些表的所有是否都有1-to-1关系？例如，每个用户行是否只在user_stats或user_levels中有一个对应的行？如果是这样，将它们组合成一个表可能是有意义的。如果关系不是 1 to 1，那么将它们组合（非规范化）可能没有意义。

除非你有数十万或数百万的用户记录，否则将它们放在单独的表和一个表中可能对性能几乎没有影响。您将获得的唯一真正收获来自于通过组合它们来简化查询。

ETA：

如果您的关注是关于列太多，那么请考虑您通常一起使用的内容并将这些内容合并，剩下的就是其余内容在一个单独的表中（如果需要，可以是几个单独的表）。

如果你看一下你使用数据的方式，我猜你会发现80％的查询都会使用20％的数据，其余80％的数据只是偶尔使用。将经常使用的20％合并到一个表中，并将80％不经常使用的表留在单独的表中，您可能会有一个很好的妥协。

Answer 5

创建一个大型表违反了关系数据库主体。我不会将它们全部合并到一个表中。您将获得重复数据的多个实例。例如，如果您的用户有三个兴趣点，那么您将拥有3行，并使用相同的用户数据来存储三个不同的兴趣。明确地采用多重“标准化”表格方法。有关数据库规范化，请参阅this Wiki页面。

修改 我更新了我的答案，因为你已经更新了你的问题......我现在更赞同我的初步答案......

  

这些细胞的很大一部分是   可能仍然是空的

例如，如果用户没有任何兴趣，如果你正常化，那么你就不会在该用户的兴趣表中有一行。如果你把一切都放在一个庞大的表中，那么你将拥有只包含NULL的列（显然很多）。

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

Answer 6

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

Wordpress专门用于允许通过插件添加功能，因此允许您的项目更具可扩展性，并且如果您需要添加新功能，则不需要完整的数据库大修。

Answer 7

我认为这是“依赖”的情况之一。拥有多个表格更清晰，理论上可能更好。但是当你必须加入6-7个表来获取有关单个用户的信息时，你可能会开始重新考虑这种方法。

Answer 8

我想说这取决于其他表格的真正含义。 user_details是否包含超过1个/用户等等。 标准化的最佳级别最适合您的需求取决于您的需求。

如果你有一个表具有良好的索引可能会更快。但另一方面可能更难维护。

对我而言，您似乎可以跳过User_Details，因为它可能与用户的关系是1比1。 但其余的可能是每个用户很多行？