我想知道什么时候我们的日志表会变得不可用。
日志表自创建以来一直在增长。我们现在有12亿排。它有3个索引，允许我们快速查询它，只要我们对请求的数据量进行时间限制。
我们不打算改变模式，使用任何与此表相关的连接查询，或者除了基于时间框架（包含在索引中的列）的帐户活动查询之外的任何内容。
我查阅了有关innodb表限制的mysql文档(https://dev.mysql.com/doc/refman/5.6/en/innodb-restrictions.html)并确定64tb的上限目前不受关注。
该计划最终是将日志记录卸载到另一个工具，并将不相关的旧日志归档。
是否有人有任何经验或文档可以帮助我确定我们还有多长时间才能遇到严重的性能问题？
我现在关心的是：
插入成为长时间运行的操作在什么时候会有问题
是否存在索引大小过大会导致严重性能问题的情况
有没有其他我应该担心的危险信号问题？
2条答案
按热度按时间7kjnsjlb1#
可能的帮助方法：
避免需要接触很多行的查询。考虑使用“汇总表”来保存每日（或每小时或其他）的小计。
3指标是问题的一部分；摘要表可能有助于消除其中的一些问题。但要保持
PRIMARY KEY. 不同的索引可能会有所帮助。收缩数据类型以减少i/o，因此速度较慢。
如果字段经常重复，请规范化并使用
JOINs; 这可能会有很大帮助。可能没有帮助的方法：
分区不会有帮助，除非您需要在一段时间后清除“旧”数据。
离麻烦还有多久？
取决于列
取决于ram大小
取决于查询的复杂性
取决于其他事情。
INSERTs除非使用uuid，否则不太可能造成麻烦。但是——汇总表通常可以将灾难推迟很长一段时间——可能是10倍。
细节。没有更多的细节，我帮不了你更多。
SHOW CREATE TABLE关于摄入率等的一些统计数字典型查询
等。
经验法则。。。典型的innodb btree（数据或索引）的扇出值为100。即每个节点下有100个“行”。因此，您的table（可能）大约有5层深。索引也是如此。通常，btree的深度对任何性能讨论都不重要。
经验法则。。。套
innodb_buffer_pool_size大约70%的内存。hgtggwj02#
当索引的常用部分不能再驻留在innodb缓冲池中时，查询将开始使用更多的io。
关于innodb树长度的讨论给出了单个查找需要读取多少个已读页面的指示，但正如您所见，b+树非常有效。显然，在缓冲池工具中保留通常的非叶节点是理想的。
所以一般来说，观察innodb\u buffer\u pool\u read\u requests与innodb\u buffer\u pool\u reads ratio在状态变量上的对比，当这个比例开始下降时，考虑更多的ram。