如果您的系统运行良好，突然开始减速到停止响应的程度，您会怎么做？您的第一反应是检查工作量的变化。这是大多数突然减速的常见罪魁祸首。假设您的工作量没有显着变化。但是，您的系统不断变慢；接下来你会去哪里检查？检查更改内容的下一个合乎逻辑的地方是配置。让我们了解跟踪 MySQL 配置中的更改。
让我们讨论一个非常相反的情况。如果您的 MySQL 服务器开始比以前更好地执行并且其工作负载没有变化，您将在哪里查看？再一次，要寻找的地方是配置。当突然发生变化时，了解与以前情况相比发生了什么变化至关重要。
今天的博客通过一个有趣的变量 innodb_read_ahead_threshold 示例讨论了保持 MySQL 配置更改历史的重要性。
MySQL 配置跟踪
让我们了解为什么必须跟踪配置更改。系统的性能取决于许多参数。让我们讨论一个特定的参数——innodb_read_ahead_threshold，我们改变了它，以及配置更改历史对我们来说是多么重要。
MySQL 引擎内置了许多性能调优机制。当 MySQL 从单个扩展中读取一定数量的页面时，它会发送一个 I/O 请求以异步方式从下一个扩展中预取缓冲池内存中的多个页面。此请求通常称为预读请求。
MySQL 配置变量 innodb_read_ahead_threshold 控制预读请求何时触发。此变量的默认值设置为 56。如果 InnoDB 在一定范围内顺序读取 56 页，则会触发读取下一页。变量innodb_read_ahead_threshold 的最小值可以设置为 0，这意味着禁用预读请求，当它设置为最大值 64 时，它会在完全读取后从下一个扩展中获取值。
如果 MySQL 引擎没有读取预读请求预取的数据，它最终会将它们从缓冲池中逐出。未从缓冲池读取和逐出的页面数由变量 Innodb_buffer_pool_read_ahead_evicted 计算。所有带入缓冲池内存的页面都使用变量
Innodb_buffer_pool_read_ahead 进行测量。这两个变量都是全局变量，并在 MySQL 服务器重新启动时重置。
如果缓冲池中读取的所有页面最终都被 MySQL 引擎使用，这总是一个好兆头。期望总页数与预读页数之比接近于零。如果该比率值接近 1，则表明引擎在优化性能方面的努力是浪费的。
页面读取和驱逐比率取决于当前工作负载和变量 innodb_read_ahead_threshold。在整个过程中，DBA 应该监控比率值，可以将阈值更改为最适合其工作负载和其他参数的值。
解决方案：MySQL 的 SQL 诊断管理器
有许多不同的变量和配置值会影响 MySQL 的性能。当任何配置变量发生变化时，DBA 需要记录性能基准值。如果性能有任何变化，DBA 应将其与配置更改的时间线进行比较以进行影响分析。我建议使用 SQL DM for MySQL来跟踪所有配置更改并将它们与性能问题进行映射。
原文标题：Tracking Changes in MySQL Configuration
原文作者：Pinal Dave
原文地址：https://blog.sqlauthority.com/2022/06/14/tracking-changes-in-mysql-configuration/
