MySQL在性能严重下降之前的最大行数

Question

我想了解我们的日志表将在什么时候变得不可用。

自日志表创建以来，日志表一直在增长。我们目前有12亿行。它具有3个索引，可让我们在对所需数据量进行时间装箱的情况下快速查询它。

我们不打算使用与该表相关的任何联接查询来更改架构，或者除了基于时间范围（即包含在索引中的列）对帐户活动的查询之外，不会进行任何更改。

我已经研究了有关InnoDB表限制（https://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html）的MySQL文档，并确定当前不关心64TB的上限。

最终的计划是将日志记录卸载到另一个工具上，并归档不相关的旧日志。

任何人都没有任何经验或文档可以帮助我确定在遇到严重的性能问题之前我们要待多长时间？

我目前关注的是：

• 到什么时候插入会变成长期运行的问题
• 是否存在索引大小太大而导致严重性能问题的情况？
• 还有其他我应该担心的危险信号吗？

Answer 1

当索引的常用部分不能再驻留在innodb缓冲池中时，查询将开始使用更多的IO。

在innodb tree length上的讨论给出了一次查找需要读取多少个读取页面的指示，但是您可以看到B +树非常有效。显然，将通常非叶子的节点保留在缓冲池工具中是理想的。

因此，通常请注意状态变量上的Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads之比，当此比率开始下降时，请考虑增加RAM。

Answer 2

可能的帮助方式：

• 避免需要触摸很多行的查询。考虑使用“摘要表”来保留每日（或每小时或其他）小计。
• 3个索引是问题的一部分；摘要表可能有助于消除其中的一些。但是保留const Something = ({ classes, children, variant }) => { return ( <div className={classes.someThing}> <div> variant is : {variant}</div> <div className={classes.fooDisplay}>I only display if variant is foo</div> </div> ); }; 。不同的索引可能对您有帮助。
• 缩小数据类型以减少I / O，因此速度变慢。
• 如果经常重复输入字段，请标准化并使用PRIMARY KEY;可能会大大帮助您。

可能无法提供帮助的方式：

• 除非您需要在一段时间后清除“旧”数据，否则分区将无济于事。

麻烦多久了？

• 取决于列
• 取决于RAM大小
• 取决于查询的复杂性
• 取决于其他事情。
除非您使用UUID，否则
• JOINs可能不会造成麻烦。
• 但是-摘要表通常可以将灾难推迟很长时间-可能长达10次 。

详细信息。没有更多详细信息，我无法为您提供更多帮助。

• INSERTs
• 一些摄入率等统计数据
• 典型查询
• 等等。

经验法则...典型的InnoDB BTree（数据或索引）的扇出为100。也就是说，每个节点下都有100个“行”。因此，您的桌子将（可能）深约5层。同上索引。 通常 BTree的深度对于任何性能讨论都不重要。

经验法则...将SHOW CREATE TABLE设置为大约70％的RAM。