我有一些超过1亿行的表。 我每个月大约有20到40万行。
此刻一切似乎都很好： - 所有插入都很快 - 所有选择都很快（他们使用索引并且不使用复杂的聚合）
然而，我担心两件事，我在某处读过的内容： - 当一个表有几亿行时，可能会有慢插入，因为重新平衡索引可能需要一段时间（二叉树） - 如果索引不适合内存，则可能需要一段时间才能从磁盘的不同部分读取索引。
任何评论都将受到高度赞赏。 任何建议如何避免它，或者如果/当它发生时如何修复/缓解问题将受到高度赞赏。
（我知道我们应该在某天开始进行分片）
提前谢谢。
答案 0 :(得分：26)
今天是你应该考虑分片或分区的那一天，因为如果你现在有100MM的行，并且你每月大约需要30MM，那么你将在三个月内将它的大小增加一倍，并且可能会增加一倍它在年底之前再次出现。
在某些时候，您将遇到数据库太大而无法迁移的事件。要么磁盘上没有足够的工作空间来切换到备用架构，要么在需要再次运行之前没有足够的停机时间来执行迁移。然后，当它变得越来越慢时，你会永远坚持下去。
表上写活动的表现很大程度上取决于索引的维护难度。您索引的数据越多，写入的惩罚就越多。索引的类型都是相关的，有些比其他更紧凑。如果您的数据被轻微编入索引，通常可以在事情开始变得非常缓慢之前获得更多记录，但这种降级因素在很大程度上取决于您的系统配置，硬件和IO容量。
请记住，InnoDB，你应该使用的引擎，有很多调整参数，许多人将它设置为非常可怕的默认值。看一下分配给它的内存，并确保你正确地做到了。
如果您有任何方法对这些数据进行分区，例如按月，按客户或基于业务逻辑不会改变的其他因素，那么数据本质上是不相关的，您将有许多简单的选项。如果不是，你将不得不做出一些艰难的决定。
您现在要做的一件事就是模拟表中的1G行的表现。创建足够大，适当变化的测试数据量，然后查看它在负载下的性能。您可能会发现这不是问题，在这种情况下，不用担心再过几年。如果没有，请立即开始恐慌，并在数据变得太大而无法拆分之前寻求解决方案。
数据库性能通常以相当线性的方式降级，然后在某些时候它会从悬崖上掉下来。你需要知道这个悬崖的位置，以便在你击中之前知道你有多少时间。当索引无法适应内存并且磁盘缓冲区拉得太薄而无法使用时，性能急剧下降。