数据库设计的性能：一个数据库供 n 个客户使用 vs 每个客户一个数据库答案

【问题标题】：Database design's performance: One database for n customers vs a database per customer数据库设计的性能：一个数据库供 n 个客户使用 vs 每个客户一个数据库
【发布时间】：2015-05-09 13:56:16
【问题描述】：

考虑一个带有 MySQL 数据库的 Web 应用程序项目，它应该为多家公司服务。这些公司完全不相关，因此不应访问彼此的数据。我可以想到两种设计来实现这样的应用程序：

1.对表使用company_id 来指明每条记录的所有者。这样一个数据库将在多个公司之间共享。

2。为每家公司专用一个数据库。这样company_id字段将被省略，数据隔离提供了更好的安全保证。然而，多个公司将共享一个 MySQL 实例（由于项目的利润方面，不可能将一个 MySQL 实例专用于每个公司）。

如果我们假设这两种方法都是可行的（安全方面）哪一种性能更高？

我相信这一切都归结为在 MySQL 中拥有一个数据库的开销，但我不确定那是多少！

【问题讨论】：

标签： mysql performance database-design

【解决方案1】：

从性能的角度来看，差异绝对可以忽略不计。

在每个表格中都有company_id 会给每个表格等增加一点编程负担，但这是标准的做法。这将被视为“最佳实践”。

为每个公司拥有一个单独的数据库允许从公司任命一名管理员，他们可以执行例如备份或截断等操作，而不必担心看到或删除其他人的数据。 IMO，这将是使用多个数据库的唯一原因。

【讨论】：

由于省略了 company_id 索引而节省的内存（和 CPU）怎么样？大多数情况下，我对company_id 索引的成本与拥有单独的数据库之间的比较感兴趣。
我认为拥有多个数据库的开销大致相当于 company_id 索引的内存/CPU。真的，我认为“可以忽略不计”这个词是正确的答案。除非您有相对较强的业务原因，否则请使用 company_id 列和单个数据库。
如果它们的差异可以忽略不计，我宁愿采用第二种方法，因为它简单且安全性更高。
我不确定改进的安全性 - 我真的没有看到。能够在不访问 dB 的情况下从应用程序本身添加新公司，没有多个表需要在（而不是如果）进行更改时更新，等等都是 1 db 优于多个的原因。这将是“最佳实践”是有原因的。但这是你的选择 - 我的鼻子没有皮肤......
安全性在很大程度上取决于您的客户的工作方式。我希望您不要让个别公司直接连接到 MySQL。相反，我希望在两者之间有一些 API 层。如果是这样，那么这就是“安全”应该在的地方。