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