mysql - 将大量相同的 MySQL 表转换为一个和大量指向它的 View ？

Question

我正在运行一个相当大的 WPMU(Wordpress 多用户、Wordpress 多站点)部署，它使用 4096 个数据库和 100k+ 表(显然，在涉及的架构方面有很多重叠)。

基本上它是为每个博客一遍又一遍地复制的 20 多个相同的表，其中一些是空的，其他的包含几行到几百行。

我的计划(省去了很多麻烦，但可能证明效率低下)是将所有相同模式的表合并到几个大的 InnoDB 表中，并用指向它们的 MySQL VIEW 替换旧表，重写查询，以便返回相关行(将旧表名存储在新列中，然后使用 View 将列添加到查询 WHERE 子句中)。

问题是:这会在性能方面提供任何类型的改进吗？ (关键缓冲区效率、表缓存效率、索引)或者这只是蛇油，我应该采用更激进的方法重写应用程序，这样我就不需要 View ，但查询直接进入大 InnoDB表？

Answer 1

我建议不要进行您正在考虑的表合并。

考虑合并表格的一些缺点:

• 合并表的索引数据结构将更大更深，因此效率更低。
• 积累了大量数据但随后闲置的博客仍然会增加表和索引的整体大小，因此会使查询时间更长。
• 更难备份和恢复个人博客。
• 如果您想横向扩展，则很难将单个博客移动到另一个数据库服务器。
• 更难使用 SQL 权限来限制对给定博客的访问(尽管您可以将 SQL 权限应用于 View )。
• 更难添加自定义功能，包括给定博客的架构更改。

使用 View 或不使用 View 不会对上述问题产生积极或消极的影响。至少在 MySQL 中， View 基本上只是运行时的查询重写，它不会比直接查询基表更好或更差地使用索引。

我曾经与 Wordpress.com 的数据库架构师交谈过。他们在 几十个 数百台物理服务器上托管数百万个 Wordpress 博客。早期，他们开始将所有博客的数据合并到同一张表中，但随着规模的扩大，他们发现操作难度太大了。现在他们将每个博客托管在一个单独的数据库中。