我想看看哪种方法在数据库中查询更有效。
在多租户数据库中，查询只是问题的一部分。问题的其他部分是成本，数据隔离和保护，维护和灾难恢复。这些都很重要;您无法在多租户数据库中仅考虑查询效率。
多租户解决方案的范围从每个租户一个数据库（无共享）到每个租户一行（共享所有内容）。
“无共享”，“单独数据库”或每个租户一个数据库
- 每个客户最贵。 （大量客户意味着大量服务器。）
- 最高程度的数据隔离。
- 单个租户的灾难恢复简单明了。
- 维护理论上更难，因为需要在每个数据库中执行更改。但是您的dbms可能很容易支持在每个数据库中运行存储过程。 （例如，SQL Server有一个未记录的系统存储过程，sp_msforeachdb。您可以自己编写。）“无共享”也是最容易定制的，但这也会引发更多的维护问题。
- 每个表的最小行数。查询速度接近最佳状态。
“共享所有内容”，或“共享架构”，或“每个星球上的一个数据库”
- 每个租户最不贵。
- 最低程度的数据隔离。每个表都有一列，用于标识行所属的租户。由于租户行在每个表中都是混合的，因此意外暴露其他租户的数据相对简单。
- 单个租户的灾难恢复相对复杂;您必须在许多表中恢复单个行。另一方面，单租户灾难相对不常见。大多数灾难可能会影响所有租户。
- 结构维护更简单，因为所有租户共享表格。但是，它会增加通信负载，因为您必须与每个租户进行通信并协调每个更改。它不容易定制。
- 每个表的最大行数。快速查询更难，但这取决于有多少租户和多少行。您可以轻松地进入VLDB领域。
“无共享”和“共享所有内容”之间是“共享模式”。
“共享架构”
- 租户共享一个数据库，但每个租户都拥有自己的命名架构。成本介于“无共享”和“共享一切”之间;大型系统通常比“无共享”需要更少的服务器，比“共享所有内容”更多的服务器。
- 比“分享一切”更好的隔离。没有“无所谓”的隔离。 （您可以对模式进行GRANT和REVOKE权限。）
- 单个租户的灾难恢复需要恢复许多模式中的一个。这可能相对简单或相当困难，具体取决于您的dbms。
- 维护比“无共享”更容易;不像“分享一切”那么容易。编写将在数据库中的每个模式中执行的存储过程相对简单。与“无共享”相比，在租户之间共享公共表格更容易。
- 每台服务器通常比“无共享”更活跃的租户，这意味着他们共享（降级）更多资源。但没有“分享一切”那么糟糕。
微软在multi-tenant architecture上发表了一篇很好的文章，详细介绍了这些文章。 （该链接仅适用于多页文档的一页。）