哪个效率更高：多个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）这是一种可能性：您认为作为单个值的数据将来可能会变成真正的多个值。例如，信用额度到目前为止是单个值字段。但是明天，您可能会决定将值更改为（日期从，日期到，信用值）。拆分表现在可能会派上用场。
我的投票将是针对多个表-数据已适当拆分。
祝好运。
-
我有这样的表达： 以下哪些元素（
-
问题内容： 因此，这更多是一个设计问题。 我有一个主键（例如用户的ID），并且有大量与该用户相关联的信息。 我应该根据信息将多个表细分为几类，还是只有一个表包含许多列？ 我过去这样做的方法是拥有多个表，例如，一个表用于应用程序使用情况数据，一个表用于配置文件信息，一个表用于后端令牌等，以使事情看起来井井有条。 最近有人告诉我，最好不要那样做，有一个包含很多列的表也可以。关键是，所有这些列都具有相同
-
问题内容： 我正在尝试根据另一个MySQL信息更新一个MySQL表。 我的桌子看起来像： 而表如下所示： 我想更新在与来自基于（存储在字符串字段）。 希望更新后的表如下所示： 我有一个有效的查询，但是非常慢： 这使我的CPU耗尽，最终导致超时，并且仅执行了一部分更新（有数千个要匹配的值）。我知道匹配的速度会很慢，但这是我必须将它们匹配在一起的唯一数据。 有没有更好的方法来更新这样的值？如果可以更快
-
问题内容： 如果您的目标是测试MySQL列中是否存在字符串（类型为’varchar’，’text’，’blob’等），那么以下哪一项是更快/更有效/更好地使用，为什么？ 或者，还有其他方法可以胜任这些方法吗？ 与 问题答案： 正如kibibu在上述评论中指出的，FULLTEXT搜索绝对会更快。 但是 ： 在我的测试中，它们的表现完全相同。它们都不区分大小写，并且通常会执行全表扫描，这在处理高性能M
-
这是一位高级经理问的面试问题。 哪个更快？ 我说过，这两者具有相同的执行速度，因为内部的表达式最终应计算为或。在这种情况下，两者的计算结果都为，条件中没有额外的条件指令。因此，两者的执行速度相同，我更喜欢while（1）。 但面试官自信地说：“检查一下你的基础，比要快。”（他不是在考验我的信心） 这是真的吗？
-
问题内容： 我正在为具有多个“类型”用户的组织设计数据库。首先，我只创建了一个用户表。但是，尽管所有用户共享一些公共信息（名字，姓氏，用户名，密码等），但是每种用户类型都需要一个或两个其他字段，这些字段不适用于所有用户。尽管我可以创建这些附加字段并将其设置为NULL，但我不希望这样做，因为这些字段是外键，并且对我造成了麻烦。 这种情况通常如何处理？ 谢谢！ 问题答案： 您的直觉是不创建带有大量NU