MySQL性能；大数据表还是多数据表？

Question

我有一个要重建的成员(member)数据库。每个成员在主成员表中都有 1 行。从那里我将使用 JOIN 来引用其他表中的信息。我的问题是，什么对以下性能更好:

1个数据表，指定数据类型，然后是数据。示例:

数据_id |成员(member)编号 |数据类型 |数据
1 | 1 |电邮 | test@domain.com
2 | 1 |电话 | 1234567890
3 | 2 |电邮 | test@domain2.com

或者

制作一个包含所有电子邮件地址的表格，然后制作一个包含所有电话号码等的表格，然后使用具有多个连接的 select 语句会更好吗

请记住，该数据库将从成员表中的 75000 多行开始，实际上包括电话、电子邮件、传真、名字和姓氏、公司名称、地址城市状态 zip(这意味着每个成员将至少有其中每个 1 个，但可以有多个(通常每个成员 1-3 个)，因此超过 75000 个电话号码、电子邮件地址等)

所以基本上，连接 1 个超过 750,000 行的表或连接 7-10 个超过 75,000 行的表

编辑:当我们插入需要与数据库中现有数据匹配的销售数据时，此数据库的性能会成为一个问题，因此需要一个包含 10k 行销售和联系人数据的 CSV 文件并查询数据库以尝试从 CSV 中找到哪些成员属于哪个销售行？哦，是的，这是在网络服务器上完成的，而不是本地机器(不是我的选择)

Answer 1

构建此结构的明显方法是为您需要跟踪的每个数据项(电子邮件、电话等)创建一个表，其中一列。如果一个特定的数据项可以在每个成员中出现多次，那么它取决于该项目与成员之间关系的确切性质:如果该项目可以自然地出现可变次数，那么将这些放在一个单独的表，其中包含成员表的外键。但是，如果数据项可以在一组有限的、固定的角色(例如，家庭电话号码和手机号码)中出现多次，那么在成员表中为每个角色创建一个不同的列就更有意义了。

如果您遇到这种设计的性能问题(我个人认为 75000 不是那么多 - 如果您有索引来正确支持您的查询，它应该不会出现问题)那么您可以对数据进行分区。 Mysql 支持 native 分区 (http://dev.mysql.com/doc/refman/5.1/en/partitioning.html)，它实质上将行集合分布在单独的物理隔间(分区)上，同时维护一个逻辑隔间(表) ).这里的明显优势是您可以继续查询逻辑表，而不需要手动从多个地方收集数据。

如果您仍然不认为这是一个选项，您可以考虑垂直分区:即，将列分组甚至单个列放在它们自己的表中。如果您有一些查询总是需要一组特定的列，而其他查询倾向于使用另一组列，那么这很有意义。只有这样应用这种垂直分区才有意义，因为连接本身会降低性能。

(如果你真的遇到了数十亿，那么你可以考虑分片 - 也就是说，使用单独的数据库服务器来保留行的分区。只有当你可以快速限制分片的数量时，这才有意义需要查询以查找特定的成员行，或者您是否可以有效地并行查询所有分片。就我个人而言，您似乎不需要这个。)

我强烈建议不要制作单个“数据”表。这基本上会将自然成为一列的每一件事分散到一行。这需要一大堆连接，并使原本非常简单的查询的编写变得复杂。不仅如此，它还几乎不可能为您的数据创建适当、高效的索引。最重要的是，它使得对数据应用约束变得非常困难(比如根据类型强制执行数据项的数据类型和长度)。

在一些极端情况下，这样的设计可能有意义，但提高性能并不是其中之一。 (参见:实体属性值反模式 http://karwin.blogspot.com/2009/05/eav-fail.html)