对于试图设计可伸缩的MySQL数据库的开发人员来说，有哪些好的建议？

Question

正如问题所述，我是一个开发人员，而不是一个DBA。我有设计好的ER模式的经验，并且对规范化和好的模式设计相当了解。我还与数据仓库一起工作，这些数据仓库使用带事实表和dim表的维度建模。

然而，我在以前的工作中开发的所有数据库驱动的应用程序都是公司内部网上的内部应用程序，从来没有收到“真实世界的流量”。此外，在以前的工作中，我一直有一个DBA，或者对这些事情比我了解得更多的人。

在我刚刚开始的这一新工作中，我被要求开发一个带有MySQL后端的面向公共的应用程序，并且这个应用程序存储的数据预计会迅速增长。哦，我们没有DBA。我想我就是DBA了。;)

至于设计一个可伸缩的数据库，我甚至不知道从哪里开始。对于那些被推入DBA/数据库设计人员角色并负责设计可扩展数据库以支持这样的应用程序的开发人员来说，有谁有任何好的提示或者知道有什么好的教育材料吗？有没有其他开发人员经历过这类事情？你做了什么才能迅速地胜任这个角色？

我在主题这里上找到了一些很好的幻灯片，但是很难从幻灯片中收集细节。真希望我能参加那家伙的演讲。

我还发现了一个名为增强MySQL可伸缩性的5种方法的好博客，它有一些好的信息，尽管有些信息超出了我的想象。

tl；

博士

我只想确保数据库不需要在扩展时被完全重新设计，我正在寻找第一次正确处理它的技巧。我正在寻找的答案是“每个开发人员都应该知道的关于建立一个可伸缩的MySQL数据库的事情清单，这样当数据变得巨大时，应用程序就不会像垃圾一样执行”。

Answer 1

我认为通常的规则适用于：

• 保持桌子小(不要不必要地浪费空间)。
• 不要查询比您需要的更多信息。
• 如果您使用ORM，请注意常见的缺陷，如N+1问题。
• 远离麻烦的操作符(例如'%Smith%')。
• 明智地设计你的索引，并确保它们涵盖了大多数的使用(这里是一个不错的，如果轻的话，索引的处理)。
• 记住，基于集合的查询在性能上通常比迭代数据要好得多。
• 因为性能原因，知道什么时候去还原数据。
• 缓存任何可以缓存(经济)的东西来释放DB。

当然，垂直缩放只能让你走到目前为止，然后你可能需要观察水平缩放。尽管如此，一个好的单DB设计仍然可以帮助您--据我所知，StackOverflow仍然在运行单个DB实例。如果您认为您需要处理更多的数据，请考虑在早期进行切分(或其他DBs)。

Answer 2

可伸缩性在很大程度上取决于数据库模式设计，而更少依赖于数据库性能。

我建议如下场景创建良好的数据库模式。

1. 尽可能地规范架构。
2. 然后，如果您有任何链接表-复制所有的键通过目标表。
3. 现在--为了得到更快的报告，对所有的表稍微去修饰。

Answer 3

• 尽可能由PK选择；
• 将表保持足够小，以便所有索引都能存储在内存中。如果这是不可能的，垂直切碎。如果一些表很少或从来没有一起使用，那么应该很容易；
• 尽可能避免JOINs，但另一方面不要落入1+N陷阱；
• 避免SELECT *，特别是如果任何列都是LOB (如TEXT)。LOB从不缓存在内存中，它们总是从HDD中获取；
• 有用于交互查询的专用辅助服务器，以及用于缓慢、复杂、聚合报表查询的单独的辅助查询；
• 使用InnoDB (当前MySQL中的默认值)；
• 使用奴隶为SELECTs，主人为INSERT/UPDATE/DELETEs；
• 批处理类似的查询(如。如果您在每个页面视图上都有一个insert，不要立即执行数据库操作，而是将其放入缓存中，然后在insert中使用多个值；