我正在研究一个相对较小的数据库。它共有67个表格，有一百多万条记录。它大约是254 MB。与它一起工作的应用程序已运行了大约5年，每年的使用量翻了一番。今年我们预计将增长三倍，这将使数据库的规模几乎翻倍一季。我的问题是，将数据库分成多个数据库是一个坏主意。假设我们有300个客户端，那么它会创建300个包含67个表的个人数据库，但只包含与该客户端有关的数据。除了可以在不同的服务器上执行的内部统计数据之外，没有太多的数据合并的原因。我们不应该在一生中超过10,000个客户。每个客户端拆分mysql数据库
的问题，我看到这个设置是当我们需要作出改变，以“主数据库”模式就需要复制整个所有的“从数据库”
而且复制将是一个挑战的变化当一个新的客户端被添加。
代码级别的应用程序几乎为这种类型的设置设置。
有什么我失踪？这是一个可怕的想法？
数据库是在匆忙中（而不是我）创建的，没有考虑到未来，现在这是我的责任。
就规范化，字段类型审计，sql优化，索引和服务器调整而言，还有很多工作要做。任何反馈将不胜感激。
我的问题是如何访问数据库？每个客户端是否安装一个应用程序？如果是这样的话，那么在升级应用程序时保持数据库的独立性可以为您提供一些时间（因为您只需在更新应用程序时更新数据库）。如果通过一次应用程序安装访问它们，请将它们放在一起。
但还有其他的考虑因素。你提到今天的大小是100万行@ 256 MB。这应该很容易在商品服务器的范围内。所以如果你预计最坏的情况会每年增加5倍，那么今年你会说500万行，其次是25次，125次是第三次，625次是第四次，3125万次是第五次。即使是30亿行（取决于查询的确切用法和类型）对于MySQL来说也不是很难处理（仍在商业服务器的上限范围内）...
另外，如果您开始运行的问题，你总是可以partition每个上client键（或只是大表）...它自动由MySQL替您管理的，所以你不必自己管理它们的维护的噩梦......
目前你有四分之一的数据。你预计今年会增加一倍（半个演出）。是1997年吗？不，它是2010年，人们在他们的电话上有千兆字节的数据。
所以问题是，你试图解决什么问题？它不能存储，因为这是一个微不足道的数据量。如果是性能，那么我认为拆分成多个数据库很可能会让事情变得更糟，因为每个数据库都会设想一台服务器。从安全角度来看，对于单独的数据库有争论，但解决这些问题的方法有很多。
您对当前环境有问题吗？或者至少有一些趋势表明你可能在十二个月内遇到问题？如果不是，那么就坐稳。如果是的话，清楚地阐明它们，然后弄清楚300个数据库将如何解决这些问题，以及它们是否值得不可避免的悲伤。然后重新调整这个悲伤来解释10000个用户并再次提出问题。
可能有一些问题的最佳答案是“万个数据库”，但不是很多。
“我们最大的客户增加了约12000 记录每年。”
也就是说大约每十个工作分钟（假定一个八小时工作日）一个记录。这似乎不是一个大的写入负载。
“我们的想法是而不是客户端去 通过所有的数据，它只是访问 他们的数据。”
但这并不是很多数据，当然也没有什么体面的索引策略无法解决。
我还是不明白你是否有实际的问题现在或者你只是想在未来某个时候可能会有问题的东西。
修改当前模式以接纳多个客户端，如果在到达第n个客户端时性能受到影响（并且SELECT优化不起作用），则可以添加新服务器。在我们的案例中，我们将数据分为“网站”，因此一个用户无法访问不在其网站上的数据。
你有你的双手满“正常化，字段类型的审计，SQL优化，索引和服务器优化”
没有充分的理由拆分成300个数据库。还有很多不好的理由，你已经阐明了。只要CustomerId通过数据库清楚地分离客户数据，就没问题。
因此，你必须努力工作，不要给自己更多不必要的工作。
当数据库大小和速度不佳时，需要转向一个真正的SQL平台。
让我们看看SAP ERP。它可能可以容纳数千个客户和数十亿次重做。它是电力系统。其中的所有表（系统表除外）都有一个指定客户端的“MANDT”字段。 Offcource SAP通常与ORACLE协同工作，但在您的情况下，由于数据量很小，SAP不够用。
因此，根据SAP关于MySQL成功的关于MySQL的良好意见和良好的意见，我可以得出结论：您不应该在客户端之间滑动数据库。这不会产生太多
它是一个Web应用程序。然后对测试客户端进行更改，然后进行部署。 – rizzo0917 2010-08-18 15:13:34
没错，但有一个Web应用程序的实例，对吧？意思是只有一个网站访问所有数据（而不是为每个客户创建不同的网站）... – ircmaxell 2010-08-18 15:20:25