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

Question

当前设计

以前，我的同事设计了一个数据库，其中包含customer_0，customer_1等表格，以及customer_9 wherby所有客户ID根据id的最后一位数分成10个不同的表格。

此设计存在问题：

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

我的设计

为了找出解决方法，我开始知道你可以做表格分区，这完全解决了我的问题。参考this问题。

具有分区方法的Prblem

现在这个方法的问题是你不能在分区中拥有外键约束，所以这不能解决问题。

数据库分片或＆＃34;无共享＆＃34;

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

我的问题

我现在应该怎么做，我不能放弃外键约束，选择表分区。 我应该放弃所有分区和分片，只关注传统模式，并将分片部分留给DBA吗？

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

Answer 1

是的，暂时放开分区和分片 - 坚持使用传统的简单模式。您可能已经获得了许多更容易选择的水果，可以满足您的性能需求，并且能够根据您记录的数据大小设置FK约束。

你正在做的所有'分片'似乎有人为过去的优化而过早地进行优化，如果你所有的增长都达到1000万客户/记录，那么甚至都没有预料到。

另外，我真的不会把你的情况归类为“大数据”，尽管这个术语在各处都被抛出。

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

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

我怀疑你需要使用表格分区才能在你指定的数据大小上获得良好的性能。