大于 10mm 记录的数据库的 MySQL 结构

Question

我正在使用一个应用程序，该应用程序有 3 个表，每个表都有超过 10 毫米的记录且大于 2GB。

每次插入数据时，三个表中的每一个都至少添加一条记录，甚至可能更多。每次 INSERT 后都会启动一个脚本，该脚本会查询所有这些表，以提取与最后一个 INSERT 相关的数据(我们将其称为聚合脚本)。

将数据库划分为更小的单元并跨不同服务器划分以使每个服务器的负载可控的最佳方法是什么？

注释:
1. 每秒插入次数超过 10 次，因此聚合脚本运行相同的次数。
2.聚合脚本占用资源
3. 必须对所有数据运行聚合脚本，才能找到与最后插入相关的数据
4.我还没有找到一种方法以某种方式将数据库划分为更小的单元
5.我对分布式数据库知之甚少，所以请使用非常基本的术语，并尽可能提供进一步阅读的链接

Answer 1

从数据库的角度来看，这个问题有两个答案。

1. 找到一种将数据库分解为更小的单元的方法。这很大程度上取决于您数据库的使用。这确实是您最好的选择，因为这是让数据库一次查看更少内容的唯一方法。这称为分片:
   http://en.wikipedia.org/wiki/Shard_(database_architecture )

2. 拥有多个处于只读模式的“从属”数据库。这些基本上是数据库的副本(有一点滞后)。对于任何可以接受延迟的只读查询，它们会通过整个站点中的代码访问这些数据库。这将减轻您正在查询的主数据库的一些负载。但是，对于任何特定查询，它仍然会占用大量资源。

从编程的角度来看，您已经拥有几乎所有信息(除了 ids)。您可以尝试找到某种方法来使用该信息来满足您的所有需求，而不必在插入后重新查询数据库。您可以有一些进程只创建您首先查询的 id。假设您有表 A、B、C。您还有其他表，它们仅具有 A_ids、B_ids、C_ids 等主键。第一步，从 id 表中获取新的 id。第二步，插入A、B、C，同时做任何你想做的事情。

此外，还应审查所有查询的总体效率/性能。确保您正在查询的任何内容都有索引。对您正在运行的所有查询进行解释，以确保它们正在使用索引。

这确实是中级/高级 dba 要做的事情。询问你的公司，让他们帮助你并教你。