在mysql中处理大数据的最佳方法

Question

当前设计

以前我的同事设计了一个数据库，其中包含诸如 customer_0、customer_1.... 到 customer_9 之类的表，其中所有客户 ID 根据 ID 的最后一位数字分为 10 个不同的表。

这种设计的问题：

1. 我认为这不是标准做法
2. 要处理它，您始终必须将查询创建为字符串，无论是在存储过程中还是在代码中，您传入 id 并在运行时创建查询，提取 id 的最后一位数字，然后选择表查询。
3. 要应用外键约束，您需要以相同的方式拆分引用的表（我不会在这里使用术语分区，因为这种类型的拆分不是分区），即使它们不打算存储大量数据，例如customer_sales 表也必须分成 10 个部分，因为您必须应用外键约束。 （客户与 custoemr_sales 具有一对多关系）

我的设计

在寻找解决方法时，我知道您可以进行表分区，这完全解决了我的问题。参考this问题。

分区方法的问题

现在这种方法的问题是分区中无论如何都不能有外键约束，所以这并不能解决问题。

数据库分片或“无共享”

然后我遇到了这个问题，您在其中使用模式复制，我理解的是在不同的物理位置复制模式，因此根据特定的分片键查询相应的模式。

我的问题

现在该怎么办，放不下外键约束，选择表分区。 我是否应该放弃所有的分区和分片，只关注常规模式，而将分片部分留给 DBA？

注意：最大预期客户群为 1000 万。

Answer 1

是的，暂时放弃分区和分片——坚持使用传统的简单模式。您可能有许多更容易挑选的水果，它们可以在您记录的数据大小下具有 FK 约束，从而满足您的性能需求。

您正在做的所有“分片”似乎有人为未来的过早优化而采取了行动，如果您的发展目标是每条记录达到 1000 万客户，这甚至是无法预料的。

此外，我真的不会将您的情况归类为“大数据”，尽管这个词无处不在。

假设一个表有合理数量的列，比如少于 30 列，每列少于 32 个字节 (char(32))，当正确索引并给予足够的内存来保存 innodb 时，1000 万行对于 Mysql 来说没什么可处理的内存中的表（我假设您使用的是 innodb）。我目前在 AWS xlarge RDS 实例上处理的表是其大小的 10 倍，除了偶尔执行 sql 转储或更改表所需的时间之外，没有任何问题。

我会将所有不同的客户表合并到一个表中，并仔细查看您遇到的所有查询。对它们运行解释以查看您真正需要索引的位置。根据需要保留 FK 约束，并确保根据需要具有合适的覆盖索引。

我怀疑您是否需要表分区才能在您指定的数据大小上获得良好的性能。