对于具有 10,000 多个表的 MySQL 数据库，我应该查看什么样的硬件/软件配置

Question

我正在考虑推出一个 CMS 系统，该系统需要在系统的主 MySQL 数据库中创建大约 10,000 个表。

该数据库将成为数百个小型网站前端的数据存储，每月可能会吸引大约 15 万独立访问者的适度负载，但这可能必须在短时间内扩展。

1. 我正在寻找一些关于应该使用什么样的硬件既具有成本效益又能够在需要时进行扩展的建议。

2. 我还想要一些关于软件配置的建议：即 MySQL 设置应该集群还是直接使用大量打开文件的 MySQL？

任何建议将不胜感激！

Answer 1

欢迎访问 dba.StackExchange.com 网站，看起来您很受用。所以在我回答你提出的问题之前，我会提到一些细节（希望）让你有一个好的开始：

数据库中的 10,000 个表总是错误的。

我收回之前说过的话。如果您在一台服务器上拥有所有 Microsoft 或 IBM 公司数据库，则 10k 表可能是合适的。然而，概述的数据聚合是巨大的。因此，我们将忽略“有可能是对的”并坚持使用 99% 的统计非异常值。出于所有意图和目的，如果您向 dba 建议 10,000 个表，他们会嘲笑您。

我要冒险猜测你的表格看起来像：（我不是指确切的结构，我是指结构的概念）

website1_articles
website1_navigation
website1_overhead
website1_blogs
website2_articles
website2_navigation
website2_overhead
website2_blogs
.......
website375_articles
website375_navigation
website375_overhead
website375_blogs

这将（对于这个非常简单的例子）产生 1500 张桌子。但是，如果您会注意到，每个网站上唯一发生变化的是网站 ID。

相反，我可以规范化以在每条记录中包含一个网站 ID，并将整个混乱减少到四个表。

现在，我知道你在想什么：

“但这意味着我必须重做我的整个数据库架构，这会毁了一切。”

或者你在想：

“但这会破坏安全性，因为那样任何人都可以阅读其他人的网站信息”

但实际上 a) 您已经通过建议 10k 表杀死了数据库，并且 b) 这与您的建议没有任何不同。

当然，我在这里完全有可能是错的，但是任何时候有人建议 10k 表，这就是他们正在学习的课程。这是错误的。

所以这是我今天的教学内容：

SQL 是关于集合的。您应该真正考虑到 SQL 的强大之处在于它能够快速轻松地处理集合，以及该语言解析一组查询参数的相关匹配项的能力。这对您来说意味着 SQL 的目的是拥有一个包含所有博客文章的大型表（提取单个示例，这可能合适也可能不合适）并通过查询从表中选择匹配的博客文章。

此外，您询问打开的文件，但仅此而已，通过执行我上面的建议，您最多有四个表需要担心打开的文件。如果你真的很好奇，那就是“大男孩通常如何解决这个问题”。

但是你问的关于打开文件和其他微优化的事实让我认为

我想在这里提出的真正观点是：不要尝试根据您认为可以优化数据库的方式来重新设计数据库，因为您不是数据库工程师。

虽然这似乎有点苛刻，但事实并非如此。我向你保证。如果您是一名数据库工程师，或者在数据库核心开发团队工作，您就会知道这些问题的答案。因此QED。但是您必须明白，对于像您所做的那样的经验 DBA 来说，这听起来是什么；这试图通过理论而不是理性的方法来优化数据库。

现在，说了这么多，虽然有点苛刻，而且似乎完全拒绝了你的请求，我想询问更多细节，这样我才能真正专注于回答你提出的问题，尽管如此，如果我可以冒险猜测，你已经离开并忽略了我在第二段之后不得不说的一切。

因此，考虑到这一点，以下是使这个问题更易于回答的原因：

你在什么平台上运行这个？有多少个磁盘？它们的大小和速度是多少？什么版本的操作系统？如果是 Linux，您打算运行什么发行版？这会在虚拟机中吗？将来是否会支持更新，或者您是否需要一个支持一次并忘记的框？（意味着可以忽略不计的长期支持预算）

如果我可能会问，您为这个将有 10k 表的数据库使用什么框架？我要求个人的好奇心。