现在有一个Web应用程序处于生产模式3年左右。从历史上看，由于不同的原因，决定使用每个客户安装数据库。
现在我们发现现在的部署非常缓慢。
我们是否应该考虑将所有数据库移回单一数据库以降低环境复杂性？还是风险太大？
我现在看到的问题是，将这些数据库与保存参照完整性合并起来非常困难（不同数据库表的主键无法明显区分）。
数据库并不是那么大，因此我们通过拥有多个数据库来减少负载并没有多大好处。
答案 0 :(得分：1)
对于迁移的数据...客户一个数据库UUID可以从10000000开始，客户两个数据库UUID可以从20000000开始。客户三个数据库UUID可以从30000000开始......
在我看来，当您为客户托管数据库时，处理多个客户的单个数据库总体上是一个更好的主意。当然，您需要添加一个“customers”表来记录客户，并在表中包含所有顶级数据的“customer_id”列，并在所有SQL中包含检查以确保客户的视图仅限于他们的自己的数据。
我建立了一个带有附加列的新数据库，然后用一个虚拟客户或三个来测试它一段时间以确保所有错误都被消除。然后，我将逐个迁移所有客户，进行数据适合的检查。
答案 1 :(得分：1)
你的问题很广泛。
a）确保合并后的数据库不会受到JOIN语句等性能下降的影响，比如合并1000个数据库，即使每个数据库都很小。至于你的引用完整性......我假设它基于auto_increment ...你可以通过改变模式和取代UUID或类似的唯一的非顺序值来替换这些关系。或者甚至是代理密钥对以及自动增量PK。
b）执行基准测试以确保您的应用程序在性能限制内做出响应
c）这样做有直接的投资回报率吗？与迁移费用相比，长期成本效益是多少？降低的复杂性是否会增加（如果有的话）成本？
d）这对您的备份和灾难恢复计划有何影响？它会让它们更便宜吗？慢点？更贵？
抽象和管理工具方法：
如果是我，根据具体情况，我会保留每个客户端分片所带来的可扩展性，并创建一组管理工具来抽象地创建一个虚拟数据库。使用这些工具，您可以获得简化的管理，而不会失去技术灵活性。我怀疑你想要简化管理所有这些数据库的成本（基于你的部署声明）。为您的服务器场创建“控制面板”可以是简化复杂系统的好方法（特别是当部署可能使用不同的模式版本时）。