mysql - 设计关系型数据库，有一种若隐若现的厄运感

Question

我是一家拥有 200 多名用户的成长型公司的四人团队的一员。现在是对我们的专有软件进行大规模重构的时候了，我们非常高兴能够构建一个我们知道可以承受至少 5 年以上增长的理想系统。然而，我们使用的是关系数据库，虽然我们正在做一些非常棒的设计，但我有一种隐约的感觉，这个产品可能会比我们 future 希望的要慢。

我担心的是我们对外键关系的使用。它们非常适合数据完整性，这就是我们选择它们的原因。如果我们想更改某人的用户名，它会在所有相关位置进行更改。那太棒了。问题是，我们不是 - 我们通过他们的 ID 关联，所以唯一的主要好处是通过拥有关系键的索引获得的性能。

所有这些堆积起来的指数都给了我一个危险信号。我们有一些表只是链接表，具有三个关系键。他们肯定有自己的位置，我们非常有信心这会减少我们将要做的查询。但是，然后我想 - 我们在这个中有 10,000 行，在那个中有 10,000 行，在另一个中有 10,000 行，我们想添加一个新行。砰!新索引 * 4.

这令人担忧。我们是否会陷入任何陷阱，经验丰富的人有什么建议吗？

Answer 1

您当前的系统有多快？设计一个好的数据库模式是你整个应用程序的基础，如果我要在速度和设计之间做出决定，我会选择设计。有许多方法可以加速您的应用程序，这些方法与数据库本身无关。

如果您进行并行安装(将旧系统与新系统一起运行)，您可以监控慢速查询日志并在早期阶段阻止任何初始缓慢问题。您还可以识别经常运行的查询并通过添加新索引或编辑现有索引来优化查询。

您还可以实现一个缓存层，这将大大加快您的应用程序的速度。缓存充当您的应用程序和数据库之间的一层，您可以在其中以易变但可快速访问的状态存储经常请求的信息。

另一种优化技术是向上扩展(增加单台机器的物理容量)或向外扩展(通过复制在集群中添加更多机器)。我已经看到系统在具有 64GB 内存的机器上运行速度非常快，记录超过 1000 万条。因此，请确保您的设计包括物理容量。

您可以遵循大量优化技术来确保快速的数据库；远离文本列，不要使用 OR 运算符，远离 ORDER BY RAND()，并限制使用分组运算符，例如 group by。这些只是几个例子，所以做一些研究。为了使优化更容易，您可以使用诸如 MySQL 的解释之类的工具，这将确定在通过应用程序运行时查询可能有多痛苦。

我强烈推荐使用 Percona's MySQL 构建是因为它们经过高度优化并提供自定义功能。

听起来您和您的团队走在正确的道路上，不要太担心设计一个复杂的系统。一些软件应用程序需要复杂的系统才能运行。真正的诀窍是让复杂的系统易于使用，这样你就可以轻松地支持它并在未来发展它。祝你好运。