MySQL 和一个包含 100+ 百万行的表

Question

我有几个表有超过 100+ 百万行。我每个月获得大约 20-40 百万行。

此时一切似乎都很好:- 所有插入都很快- 所有选择都很快(它们使用索引并且不使用复杂的聚合)

但是，我担心两件事，我在某处读到的内容:- 当一个表有几亿行时，插入可能会很慢，因为重新平衡索引(二叉树)可能需要一段时间- 如果索引不适合内存，则可能需要一段时间才能从磁盘的不同部分读取它。

如有任何意见，我们将不胜感激。任何建议我如何避免它或如果/当它发生时我如何解决/缓解问题将不胜感激。

(我知道我们应该在某一天开始进行分片)

提前谢谢你。

Answer 1

今天是您应该考虑分片或分区的日子，因为如果您今天有 100MM 行并且您以每月约 30MM 的速度获得它们，那么您将在三个月内将其大小翻倍，并且可能翻倍在今年结束之前再次这样做。

在某些时候，您会遇到数据库太大而无法迁移的事件视界。您的磁盘上没有足够的工作空间来切换到备用模式，或者您没有足够的停机时间来执行迁移，然后才需要再次运行。然后你会永远被它困住，因为它变得越来越慢。

对表的写入事件的性能很大程度上取决于索引的维护难度。您索引的数据越多，写入的惩罚就越多。索引的类型都是相关的，有些比其他的更紧凑。如果您的数据被轻度索引，您通常可以在事情开始变得极其缓慢之前获得更多记录，但这种降级因素在很大程度上取决于您的系统配置、硬件和 IO 容量。

请记住，您应该使用的引擎 InnoDB 有很多调整参数，许多人将其设置为非常糟糕的默认值。看看分配给它的内存，并确保你做得正确。

如果您有任何方法对这些数据进行分区，例如按月、按客户或其他不会根据业务逻辑而改变的因素，即数据本质上不相关，您将有许多简单的选择.如果不是，您将不得不做出一些艰难的决定。

您现在要做的一件事是模拟您的表在 1G 行中的性能。创建一个足够大、适当变化的测试数据，然后看看它在负载下的表现如何。您可能会发现这不是问题，在这种情况下，再过几年不用担心。如果没有，请立即开始 panic ，并在您的数据变得太大而无法拆分之前寻找解决方案。

数据库性能通常以相当线性的方式下降，然后在某个时候跌落悬崖。你需要知道这个悬崖在哪里，这样你才能知道在你撞到它之前还有多少时间。性能急剧下降通常发生在您的索引无法装入内存以及磁盘缓冲区太薄而无法使用时。