长多对多数据库表：最佳性能实践答案

【问题标题】：long many to many-database table: best performance practice长多对多数据库表：最佳性能实践
【发布时间】：2016-03-18 20:18:08
【问题描述】：

我对我的 MYSQL 数据库设计的性能有疑问。

表 A 有很多记录，比如一百万，表 B 也有一百万。还有另一个表 C，其中 A 的每个记录 id 都连接到 B 中的每一行，并且这个连接有一个附加值 1 或 0。所以从功能上讲，A 中的每个记录都有一个布尔向量，其中 B 包含“变量”向量和 1 或 0 是值。底部的图片更形象地解释了这一点。

表 C 将有很多写入和读取操作（从 A 的记录中选择所有值），因此该表被非常积极地使用。而且表 C 真的很长，一百万乘以一百万行。

我的第一个问题是，桌子的长度会给出表现吗问题？数据库需要非常快。
我的第二个问题是，如果这设计不好，是否有更好的设计来实现我想要的。例如，我可以考虑将每个 A 记录的整个 B 向量存储在 A 中的每一行内。然后表 C 将不是必需的。但这会使选择、阅读和写作变得更加困难。

【问题讨论】：

【解决方案1】：

表设计很好，应该没有问题，因为您通过应该索引的 ID 访问记录。根据您的典型查询，您还应该考虑添加复合索引（c(a_id,b_id)、c(a_id,value)、c(b_id,value)、c(a_id,b_id,value)）。

但是，由于只存在两种状态，0 和 1，您可以决定只存储其中一种。 IE。如果您仅存储所有状态 1 记录，则所有不在表中的对都隐含状态 0。当状态分布不均匀时（例如 90% 的记录具有状态 0，只有 10% 的记录具有状态 1）或者您通常只访问其中一个状态（例如，您总是寻找 1），这尤其值得。

【讨论】：

去掉C_id；这是浪费空间，它会减慢速度。取而代之的是PRIMARY KEY(a_id, b_id)。您可能需要从另一个方向访问内容，INDEX(b_id, a_id) 也是如此。而且，是的，摆脱value。

【解决方案2】：

具有多次读写的表中的数百万条记录不会是如果您遵循 mysql 的最佳实践，则会遇到瓶颈。

你的引擎应该是 innodb。

您的选择查询不应涉及全表扫描。

您的表应该有所需的索引。

您应该寻找所有可能的用例，因为任何一种方式都是如果用例支持，这是个好主意。

如果您将数据拆分到多个表中，则连接操作是必要时执行。

【讨论】：