控制 InnoDB 缓冲已更改数据的类型，以避免频繁的小规模磁盘写入。参见 配置变更缓冲。启用变更缓冲可以在 IO 受限的工作负载下提供更好的性能，但在恢复、大量加载或缓冲池调整大小期间可能会引发问题。即使可能降低性能，禁用它（从 MySQL 8.4 起默认）也有助于确保稳定性。Controlling the types of data change operations for which InnoDB buffers the changed data, to avoid frequent small disk writes. See Configuring Change Buffering. Enabling change buffering can give better performance on IO-bound workloads, but can cause issues during recovery, bulk load, or during buffer pool resizing. Having it disabled (default as of MySQL 8.4) helps ensure stability even if it may lower performance.

使用 innodb_adaptive_hash_index 选项打开或关闭自适应哈希索引功能。更多信息请参见 第 17.5.3 节，“自适应哈希索引”。在异常活动期间，您可能会更改此设置，然后将其恢复为原始设置。Turning the adaptive hash indexing feature on and off using the innodb_adaptive_hash_index option. See Section 17.5.3, “Adaptive Hash Index” for more information. You might change this setting during periods of unusual activity, then restore it to its original setting.

如果上下文切换成为瓶颈，可以设置 InnoDB 处理的并发线程数的限制。请参见 第 17.8.4 节，“为 InnoDB 配置线程并发”。Setting a limit on the number of concurrent threads that InnoDB processes, if context switching is a bottleneck. See Section 17.8.4, “Configuring Thread Concurrency for InnoDB”.

控制 InnoDB 通过预读取操作进行的预取量。当系统有未使用的 I/O 容量时，更多的预读取可以提高查询性能。在负载较重的系统上，过多的预读取可能会导致性能周期性下降。参见 第 17.8.3.4 节，“配置 InnoDB 缓冲池预取（预读取）”。Controlling the amount of prefetching that InnoDB does with its read-ahead operations. When the system has unused I/O capacity, more read-ahead can improve the performance of queries. Too much read-ahead can cause periodic drops in performance on a heavily loaded system. See Section 17.8.3.4, “Configuring InnoDB Buffer Pool Prefetching (Read-Ahead)”.

增加用于读或写操作的后台线程数，如果您拥有未被默认值充分利用的高端 I/O 子系统。参见 第 17.8.5 节，“配置后台 InnoDB I/O 线程数”。Increasing the number of background threads for read or write operations, if you have a high-end I/O subsystem that is not fully utilized by the default values. See Section 17.8.5, “Configuring the Number of Background InnoDB I/O Threads”.

控制 InnoDB 在后台执行的 I/O 量。请参见 第 17.8.7 节，“配置 InnoDB I/O 容量”。如果你观察到性能周期性下降，可能需要降低此设置。Controlling how much I/O InnoDB performs in the background. See Section 17.8.7, “Configuring InnoDB I/O Capacity”. You might scale back this setting if you observe periodic drops in performance.

控制决定何时 InnoDB 执行某些类型后台写入的算法。请参见 第 17.8.3.5 节，“配置缓冲池刷新”。该算法对某些类型的工作负载有效，但对其他类型无效，因此如果你观察到性能周期性下降，可能需要禁用此功能。Controlling the algorithm that determines when InnoDB performs certain types of background writes. See Section 17.8.3.5, “Configuring Buffer Pool Flushing”. The algorithm works for some types of workloads but not others, so you might disable this feature if you observe periodic drops in performance.

利用多核处理器及其缓存内存配置，以将上下文切换延迟降到最低。参见 第 17.8.8 节，“配置自旋锁轮询”。Taking advantage of multicore processors and their cache memory configuration, to minimize delays in context switching. See Section 17.8.8, “Configuring Spin Lock Polling”.

防止一次性操作（例如表扫描）干扰存储在 InnoDB 缓冲区缓存中经常访问的数据。参见 第 17.8.3.3 节，“使缓冲池扫描具有抗干扰性”。Preventing one-time operations such as table scans from interfering with the frequently accessed data stored in the InnoDB buffer cache. See Section 17.8.3.3, “Making the Buffer Pool Scan Resistant”.

将日志文件调整到一个适合可靠性和崩溃恢复的大小。InnoDB 日志文件通常保持较小，以避免崩溃后启动时间过长。在 MySQL 5.5 中引入的优化加快了崩溃 恢复 过程中的某些步骤。特别是，由于内存管理算法的改进，扫描 重做日志 和应用重做日志的速度更快。如果你曾为了避免长启动时间而人为保持日志文件较小，现在可以考虑增加日志文件大小，以减少由于重用重做日志记录而产生的 I/O。Adjusting log files to a size that makes sense for reliability and crash recovery. InnoDB log files have often been kept small to avoid long startup times after a crash. Optimizations introduced in MySQL 5.5 speed up certain steps of the crash recovery process. In particular, scanning the redo log and applying the redo log are faster due to improved algorithms for memory management. If you have kept your log files artificially small to avoid long startup times, you can now consider increasing log file size to reduce the I/O that occurs due recycling of redo log records.

配置 InnoDB 缓冲池的大小和实例数量，这对于具有多 GB 缓冲池的系统尤其重要。参见 第 17.8.3.2 节，“配置多个缓冲池实例”。Configuring the size and number of instances for the InnoDB buffer pool, especially important for systems with multi-gigabyte buffer pools. See Section 17.8.3.2, “Configuring Multiple Buffer Pool Instances”.

增加最大并发事务数，这会显著提高最繁忙数据库的可扩展性。参见 第 17.6.6 节，“撤销日志”。Increasing the maximum number of concurrent transactions, which dramatically improves scalability for the busiest databases. See Section 17.6.6, “Undo Logs”.

将清理操作（一种垃圾收集）移动到后台线程。参见 第 17.8.9 节，“清理配置”。要有效测量此设置的效果，请先调整其他与 I/O 和线程相关的配置设置。Moving purge operations (a type of garbage collection) into a background thread. See Section 17.8.9, “Purge Configuration”. To effectively measure the results of this setting, tune the other I/O-related and thread-related configuration settings first.

减少 InnoDB 在并发线程之间的切换次数，以便在繁忙的服务器上 SQL 操作不会排队并形成“交通堵塞”。为 innodb_thread_concurrency 选项设置一个值，对于高性能的现代系统大约可设置为 32。增加 innodb_concurrency_tickets 选项的值，通常设置为大约 5000。这个选项组合会设定 InnoDB 在任一时刻处理线程的上限，并允许每个线程在被切换出去之前完成大量工作，从而保持等待线程的数量较低，使操作能够在不产生过多上下文切换的情况下完成。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.