哪种更高效：多个MySQL表或一个大表？
我在我的MySQL数据库中存储各种用户详细信息。最初它被设置在各种表格中，意味着数据与UserIds链接，并通过有时复杂的调用输出，以根据需要显示和操作数据。建立一个新的系统，将所有这些表合并成一个相关内容的大表格几乎是有道理的。哪种更高效：多个MySQL表或一个大表？
- 这会是一个帮助还是障碍？
- 调用，更新或搜索/操作时的速度考虑因素？
下面是我的一些表结构（S）的例子：
- 用户 - 用户ID，用户名，电子邮件，加密的密码，注册日期，IP
- user_details - Cookie数据，姓名，地址，联系方式，工作单位，人口统计数据
- user_activity - 捐款，最后在网上，最后一次观看
- user_settings - 个人资料显示设置
- user_interests - 广告定位的变量
- user_levels - 访问权限
- user_stats - 命中，吻合
编辑：我upvoted所有的答案到目前为止，它们都具有的元素，基本上回答我的问题。
大部分表格都有1：1的关系，这是造成非规格化的主要原因。
如果表格跨越100列以上时会出现问题，当这些单元的大部分可能保持空时？
多个表帮助在以下方面/情况：
（a）如果不同的人将要涉及到不同的表开发应用程序，是有意义的分割。 （b）如果您希望为不同的人提供不同的权限以用于数据收集的不同部分，那么将它们拆分可能会更方便。 （当然，您可以查看定义的视图并适当授予它们）。 （c）为了将数据移动到不同的地方，尤其是在开发过程中，使用导致较小文件大小的表格可能是有意义的。 （d）较小的足迹可能会让您感到舒适，同时您开发的应用程序只针对单个实体的特定数据收集。 （e）这是一种可能性：您认为单一价值数据在将来可能变成真正的多重价值。例如信用额度是目前的单一价值领域。但是明天，您可能会决定将这些值更改为（从日期到日期，信用值）。拆分表格现在可能会派上用场。
我的投票将用于多个表 - 数据适当地分割。
祝你好运。
有多个表会有任何性能下降？ – 2016-09-01 03:33:34
组合这些表称为反规范化。
它可能（或可能不会）帮助做出一些查询（使大量JOIN s）以创建维护地狱为代价运行得更快。
MySQL只能使用JOIN方法，即NESTED LOOPS。
这意味着对于驱动表中的每个记录，MySQL在循环中定位驱动表中的匹配记录。
查找记录是相当昂贵的操作，可能需要数十倍的纯记录扫描时间。
将所有记录移动到一个表中将帮助您摆脱此操作，但表本身变得更大，并且表扫描需要更长的时间。
如果您在其他表格中有很多记录，那么增加表扫描可能会超出正在顺序扫描的记录的好处。
保证地狱，另一方面，是有保证的。
如果您有10000个用户，并且您正在使用正确设置外键的数据库进行连接，那么您应该只需要通过执行类似select * from *的强大查找，其中name =“bob” 。一旦你有了bob，那么你正在使用一个索引来查找连接的表来bob，因为你使用了bob的id，所以它显着更快。无论您是在查询中查询还是查询bob，然后单独查询表，都会发生这种情况。当然希望你的第二个查询是基于bob的id而不是别的。 – 2016-09-12 16:37:16
创建一个大型表违背了关系数据库的原则。我不会把他们全部合并成一张桌子。你将获得重复数据的多个实例。例如，如果您的用户有三个兴趣爱好者，那么您将拥有3行，并使用相同的用户数据来存储三种不同的兴趣爱好。 Definatly去多个'规范化'的表格方法。请参阅this维基页面以进行数据库规范化。
编辑： 我已经更新我的答案，因为你已经更新了你的问题。我现在更因为我最初的回答同意...
这些细胞中的大部分是 可能保持空
如果例如，用户没有任何的兴趣，如果你正常化，那么你简单的不会有在该用户的兴趣表中的一行。如果你拥有一个巨大的表格中的所有东西，那么你将会得到仅包含NULL的列（显然它们中的很多）。
我曾经在一家电话公司工作，那里有大量的表，获取数据可能需要很多连接。当从这些表中读取数据的表现非常关键时，那么创建的程序可能会生成一个不需要连接，计算等报表指向的平坦表格（即非规格化表格）。这些地方随后与SQL服务器代理一起使用，以某些时间间隔运行作业（即每周查看某些统计信息将每周运行一次等等）。
我认为这是“这取决于”的情况之一。拥有多个表格更清洁，理论上可能更好。但是，如果您必须加入6-7个表才能获取有关单个用户的信息，则可能会开始重新考虑这种方法。
是否全部那些表有1-to-1的关系？例如，每个用户行在user_stats或user_levels中只有一个对应的行吗？如果是这样，将它们合并成一个表格可能是有意义的。如果关系不是1 to 1虽然，它可能没有意义合并（非规范化）他们。
将它们放在单独的表格中与一张表格相比，可能对性能影响不大，但除非您拥有数十万或数百万的用户记录。你会得到的唯一真正的好处是通过结合它们来简化你的查询。
ETA：
如果您关注是关于有太多的列，后来想想什么东西，你通常使用起来并结合这些，留下其余的在一个单独的表（或几个独立表如果需要）。
如果你看看你使用数据的方式，我猜你会发现80％的查询使用了20％的数据，其余80％的数据只是偶尔使用。将经常使用的20％组合到一张表中，并将不经常使用的80％留在单独的表中，这样可能会有很好的折衷。
是的，每个用户只有一行，每个用户只有一行，只是为了节省管理大量重复数据的头痛。这就是为什么我认为一桌适合。如果用户数据跨越多行，我希望将这些表与主用户表分开。 – 2009-07-14 12:28:19
如果每个表格都有1对1的关系，那么一张表格会更容易使用。在这种情况下，不需要拆分表格。 将表拆分为超过1行，这可能导致另一个开发人员以这种方式对待它们的情况。 – 2009-07-14 12:34:44
我想说这取决于其他表的真正含义。 user_details是否包含多个/多个用户等等。 标准化的哪个级别最适合您的需求取决于您的需求。
如果您有一张表格的索引良好，可能会更快。但另一方面可能更难以维护。
对我来说，它看起来像你可以跳过User_Details，因为它可能与用户有1对1的关系。 但其余的可能是每个用户的很多行？
他们都是1：1关系吗？我的意思是，如果用户可能属于不同的用户级别，或者用户兴趣表示为用户兴趣表中的多个记录，那么合并这些表就不会立即产生问题。
关于以前关于规范化的回答，必须说数据库规范化规则已经完全忽略了性能，并且只考虑了什么是整洁的数据库设计。这通常是你想要达到的目标，但是有些时候，为了追求绩效而主动去规范化是有意义的。
总而言之，我想说问题归结为表格中有多少个字段，以及它们被访问的频率。如果用户活动通常不是很有趣，那么总是将它放在同一个记录上，对于性能和维护原因可能只是令人讨厌。如果某些数据（如设置）经常访问，但只包含太多字段，则合并这些表可能不太方便。如果您只对性能增益感兴趣，可以考虑其他方法，例如保持独立设置，但将它们保存在自己的会话变量中，这样就不必经常为它们查询数据库。
我不得不完全不同意你的评论，即标准化只注重整洁并完全无视表现。在这两种情况下都存在折衷，非规范化实际上使数据完整性处于风险之中。我会说数据库的规范化实际上提高了数据库的总体性能，而不是从非规范化表中快速忽略性能提升。 – 2016-09-12 16:32:57
为什么不使用Wordpress通过拥有每个人都拥有基本用户信息的用户表，然后添加一个“user_meta”表，该表基本上可以是与用户标识关联的任何键值对。因此，如果您需要为用户查找所有元信息，您可以将其添加到您的查询中。如果不需要登录之类的东西，你也不需要添加额外的查询。这种方法的好处还可以让您的桌面向您的用户添加新功能，例如存储他们的Twitter处理或每个个人兴趣。您也不必处理相关ID的迷宫，因为您拥有一张统治所有元数据的表格，并且您将其限制为只有一个关联而不是50个。
Wordpress专门为此设置了功能通过插件添加，因此可以让您的项目更具可扩展性，并且如果您需要添加新功能，则不需要完整的数据库检修。
This [other question]（http://stackoverflow.com/questions/8685621/what-is-the-best-database-schema-to-support-values-that-are-only-appropriate-to/9460541 ＃9460541）也可能有所帮助 – 2013-10-13 05:37:51