我们已经构建了一个托管 Web 应用程序，该应用程序的开发方式是让每个客户都连接到一个单独的数据库。此应用程序是一个网络平台/发布系统，到目前为止，此设计运行良好。我们还有一个主数据库。
现在我们即将对定价模型进行一些更改，这将引入免费帐户。这应该（希望）产生更多的帐户。
有很多数据库，比如几千个（目前大约 20 个）是否存在问题？有很多优点：分离带来的安全性、可扩展性、轻松提取客户特定数据（也是可扩展性的一部分）等。
【问题讨论】：
标签： php mysql performance
我能看到的两个问题：
维护 - 如果您有数千个数据库，那么对数据库进行更改（更改表结构、修改 SP 等）将会很痛苦。当然，您可以编写更改脚本，但许多数据库出现问题的机会更多。如果您的脚本在中途失败并且您留下一些数据库有更改而一些没有更改，您会怎么做？另外，正如另一位发帖者所提到的，连接字符串、登录名/密码等的维护怎么样？
资源 - 我不确定每个数据库实例使用什么资源，但运行这么多数据库肯定会产生一些开销。如果你把它拆分到多台机器上，你又会遇到上面的维护问题。
【讨论】：
我可以理解关于安心和可扩展性的争论，即使可能没有确凿的“证据”来支持它。表更改等维护任务可以轻松自动化。数据库错误或入侵将被包含给一个客户，并且可以轻而易举地将数据库移动到不同的服务器。
另一方面，模型的批评者可能有一个观点。
为什么不简单地尝试一下呢？设置一个单独的凭据系统，将您的数据库复制 10.000 次，然后查看开销和性能是否仍然正常。
【讨论】：
我同意 TLiebe 的观点，未来维护数百甚至数千个数据库将非常困难。
更好的解决方案可能是按目的而不是按用户对数据库进行分区。您可以将配置文件、内容、站点等...作为您的逻辑分区，然后将每个分区上的用户数量限制为一定数量。然后，您将继续使用 profile1、profile2，直到用户用完为止。通过这种方式，您可以将数据分布在许多不同的机器上，但仍然让它们按功能相关。
MySpace 已将这一概念用于他们的数据库设置，目前看来相当成功。关于MySpace's Architecture 的文章。
祝你好运，希望这会有所帮助。
【讨论】：
我认为您的设计存在问题。为什么要为每个客户使用一个数据库，而不是在一个数据库中拥有一组表？据我所知，您提到的优点是我可以看到使用许多数据库的巨大开销.. + 连接字符串 + 单独的凭据。
【讨论】：
如前所述，数据库维护（包括安全性）可以编写脚本（具体取决于您的数据库服务器）。
在这种情况下，您实际上也获得了可扩展性。原因是当负载变得太大时，您可以添加另一台服务器并将一部分数据库移动到新服务器。无需重新设计应用程序。
【讨论】：