mysql - 数据库中的数据太多 - 需要做出 "replication"决策

Question

关闭。这个问题需要多问 focused 。目前不接受答案。

---

想要改进此问题吗？更新问题，使其仅关注一个问题 editing this post .

已关闭 9 年前。

Improve this question

现在我的 MySQL 应用程序出现问题。事实上，我担心几个月后可能会遇到的问题。

场景如下:我正在开发一个 Web 应用程序，将有很多客户端使用它。它是一个具有独特核心和多个适配(在同一核心上运行)的应用程序，因此所有适配的数据库都是相同的。每个改编都有一个或多个客户端使用它。

因此，我的数据库有超过 200 个表，并且某些表每个客户端每天可能有超过 500 行。我担心当数据库变得太大时，选择可能会非常昂贵。

我正在考虑创建多个数据库(相同的架构)，并且应用程序应该根据记录的客户端来决定使用哪个数据库。但我在更新模式时会遇到真正的问题(我必须更新每个数据库)。我的应用程序可以选择数据库，这不是问题。

• 你认为如果数据量很大，MySQL真的会停下来吗？
• 有没有办法轻松更新多个相同架构的数据库？
• 主/从方法可以解决我的问题吗？

我认为重要的是您要知道，在所有表中，我都有一个列告诉我该行属于哪个客户端，并且始终在所有选择查询中将其用作 WHERE 子句。

所以我需要帮助的是决定要做什么。你能帮我解答这些问题吗？您还有其他更智能的解决方案吗？

我不知道这是否重要，但我正在使用 PHP。

谢谢大家!

Answer 1

1. 停止是一个很大的词，但它可能会变得很慢。不过，从我在这里读到的内容来看，您不会拥有“大量”数据。它更多地与内存大小有关，因此您应该更关注内存大小而不是行数。只要照顾好你的索引即可。

2. 有一些系统可以管理此操作，但这取决于您获取数据库结构的方式/位置。我假设您使用 SQL 查询更改架构，但是，在所有数据库上自动执行该查询应该不会太难吧？如果它们是不同的机器，那么 Fabric 可以提供帮助。

3. 如果是阅读量过多，是的，它会解决您的问题。

注意

从我到目前为止读到的内容来看，你没有那么多数据，没有什么是 MySQL 在未来几年无法处理的。