我正在研究一个相对较小的数据库。它总共有 67 个表，有超过一百万条记录。它大约为 254 MB。与它一起工作的应用程序已经运行了大约 5 年，使用量每年翻一番。今年我们预计将增加三倍，这将使一个赛季的数据库规模几乎翻倍。我的问题是，将数据库拆分为多个数据库是不是一个坏主意。假设我们有 300 个客户端，那么它将创建 300 个单独的数据库，其中包含 67 个表，但只有与该客户端相关的数据。除了可以在不同服务器上执行的内部统计数据之外，没有太多理由将数据放在一起。在其生命周期中，我们不应超过 10,000 个客户。
我看到的问题是，当我们需要对“主数据库”模式进行更改时，它需要在所有“从属数据库”中复制更改
当添加新客户端时，复制也将是一个挑战。
代码级别的应用程序几乎是为这种类型的设置设置的。
有什么我想念的吗？这是一个可怕的想法吗？
数据库是仓促（不是我）创建的，没有考虑未来，现在是我的责任。
就规范化、字段类型审计、sql 优化、索引和服务器调优而言，还有很多工作要做。任何反馈将不胜感激。
“规范化、字段类型审计、sql 优化、索引和服务器调优”让您忙得不可开交
没有充分的理由将其拆分为 300 个数据库。还有很多很好的理由不这样做，你已经阐明了。只要 CustomerId 通过数据库明确区分 Customer 数据，就可以了。
所以做你必须做的事情，不要给自己更多完全不必要的工作。
当数据库大小和速度差时需要它，迁移到真正的 SQL 平台。
目前，您拥有四分之一的数据。你设想它今年翻一番（半场演出）。是1997年吗？不，现在是 2010 年，人们的手机上有千兆字节的数据。
所以问题是，你想解决什么问题？它不能是存储，因为那是微不足道的数据量。如果它的性能，那么我认为拆分成多个数据库可能会使事情变得更糟，除非你设想每个数据库都有一个服务器。从安全的角度来看，有一个单独的数据库的论点，但有不同的方法来解决这些问题。
您当前的环境有问题吗？或者至少有趋势表明您在十二个月内可能会遇到问题？如果没有，那就坐稳。如果是，请清楚地制定它们，然后弄清楚 300 个数据库将如何解决这些问题，以及它们是否值得不可避免的悲伤。然后重新校准该悲伤以考虑 10000 个用户并再次提出问题。
可能有一些问题的最佳答案是“万数据库”，但不是很多。
“我们最大的客户每年增加大约 12000 条记录。”
换句话说，每十个工作分钟（假设一天八小时）大约有一条记录。这似乎不是一个大的写入负载。
“这个想法不是让客户浏览所有数据，它只是访问他们的数据。”
但这不是很多数据，当然也没有什么是体面的索引策略无法解决的。
我仍然不明白您现在是否遇到了真正的问题，或者您只是在考虑将来某个时候可能会出现问题的事情。
修改当前模式以允许多个客户端，如果在到达第 n 个客户端时性能受到影响（并且 SELECT 优化没有帮助），您可以添加新服务器。在我们的例子中，我们将数据按“站点”划分，因此一个用户无法访问不在其站点上的数据。
让我们看看 SAP ERP。它可能拥有数千个客户和数十亿个记录器。它是可靠的电力系统。并且其中的所有表（系统表除外）都有一个指定客户端的“MANDT”字段。Offcource SAP 通常与 ORACLE 一起使用，但在您的情况下，由于数据量很小，它还不够。
因此，根据 SAP 成功的历史和关于 MySQL 作为良好 DBMS 的好意意见，我可以得出结论，您不应该在客户之间溜走 DB。这不会产生太多
我的问题是如何访问数据库？每个客户端是否安装一个应用程序？如果是这样，那么将数据库分开可以在升级应用程序时为您赢得一些时间（因为您只需要在更新应用程序时更新数据库）。如果它们被一个应用程序安装访问，请将它们放在一起。
但还有其他考虑因素。您提到今天的大小是 100 万行 @ 256 MB。这应该很容易在商品服务器的范围内。因此，如果您预计最坏情况下每年会增长 5 倍，那么您说的是今年 500 万行，接下来是 25 个，第三个是 125 个，第四个是 625 个，第五个是 31.25 亿行。即使是 30 亿行（取决于查询的确切用法和类型）对于 MySQL 来说也不是那么难处理（仍然在商品服务器的上限范围内）......
另外，如果您开始遇到问题，您总是可以对键上的每个（或主要表）进行分区client......它由 MySQL 自动为您管理，因此您不必担心自己管理它们的维护噩梦...... .