Documentation Home
MySQL 8.0 参考手册  / 第8章优化  / 8.5 优化 InnoDB 表  /  8.5.9 优化 InnoDB 配置变量

8.5.9 优化 InnoDB 配置变量

不同的设置最适合具有轻量、可预测负载的服务器,而不是始终接近满负荷运行或遇到高活动峰值的服务器。

由于InnoDB存储引擎自动执行许多优化,因此许多性能调优任务涉及监控以确保数据库运行良好,并在性能下降时更改配置选项。有关详细性能监控 的信息,请参阅 第 14.17 节,“InnoDB 与 MySQL 性能模式的集成” 。InnoDB

您可以执行的主要配置步骤包括:

  • 允许InnoDB在包含它们的系统上使用高性能内存分配器。请参阅 第 14.8.4 节,“为 InnoDB 配置内存分配器”

  • 控制缓冲更改数据的数据更改操作的类型 InnoDB,以避免频繁的小磁盘写入。请参阅 配置更改缓冲。因为默认是缓冲所有类型的数据更改操作,所以只有在需要减少缓冲量时才更改此设置。

  • innodb_adaptive_hash_index 使用该选项 打开和关闭自适应散列索引功能 。有关详细信息,请参阅第 14.5.3 节,“自适应哈希索引”。您可以在异常活动期间更改此设置,然后将其恢复为原始设置。

  • InnoDB如果上下文切换是瓶颈,则对处理 的并发线程数设置限制 。请参阅 第 14.8.5 节,“为 InnoDB 配置线程并发”

  • InnoDB控制与其预读操作一起执行 的预取量 。当系统有未使用的 I/O 容量时,更多的预读可以提高查询的性能。过多的预读会导致重载系统的性能周期性下降。请参阅 第 14.8.3.4 节,“配置 InnoDB 缓冲池预取(预读)”

  • 如果您有一个默认值未充分利用的高端 I/O 子系统,则增加用于读取或写入操作的后台线程数。请参阅 第 14.8.6 节,“配置后台 InnoDB I/O 线程的数量”

  • InnoDB控制在后台执行 多少 I/O 。请参阅 第 14.8.8 节,“配置 InnoDB I/O 容量”。如果您观察到性能周期性下降,您可能会缩减此设置。

  • 控制确定何时 InnoDB执行某些类型的后台写入的算法。请参阅 第 14.8.3.5 节,“配置缓冲池刷新”。该算法适用于某些类型的工作负载,但不适用于其他类型的工作负载,因此如果您观察到性能周期性下降,则可能会关闭此设置。

  • 利用多核处理器及其缓存内存配置,最大限度地减少上下文切换的延迟。请参阅 第 14.8.9 节,“配置自旋锁轮询”

  • 防止表扫描等一次性操作干扰存储在 InnoDB缓冲区缓存中的频繁访问的数据。请参阅 第 14.8.3.3 节,“使缓冲池具有抗扫描性”

  • 将日志文件调整为对可靠性和崩溃恢复有意义的大小。InnoDB 日志文件通常保持较小,以避免崩溃后启动时间过长。MySQL 5.5 中引入的优化加快了崩溃 恢复过程的某些步骤。特别是, 由于改进了内存管理算法,扫描重做日志和应用重做日志的速度更快。如果您人为地保持日志文件较小以避免启动时间过长,您现在可以考虑增加日志文件大小以减少由于回收重做日志记录而发生的 I/O。

  • 配置缓冲池的大小和实例数, InnoDB对于具有数 GB 缓冲池的系统尤其重要。请参阅 第 14.8.3.2 节,“配置多个缓冲池实例”

  • 增加并发事务的最大数量,这会显着提高最繁忙的数据库的可伸缩性。请参阅第 14.6.7 节,“撤消日志”

  • 将清除操作(一种垃圾收集)移动到后台线程中。请参阅 第 14.8.10 节,“清除配置”。要有效地衡量此设置的结果,请先调整其他 I/O 相关和线程相关的配置设置。

  • Reducing the amount of switching that InnoDB does between concurrent threads, so that SQL operations on a busy server do not queue up and form a traffic jam. Set a value for the innodb_thread_concurrency option, up to approximately 32 for a high-powered modern system. Increase the value for the innodb_concurrency_tickets option, typically to 5000 or so. This combination of options sets a cap on the number of threads that InnoDB processes at any one time, and allows each thread to do substantial work before being swapped out, so that the number of waiting threads stays low and operations can complete without excessive context switching.