8.5.9 Optimizing InnoDB Configuration Variables 优化InnoDB 配置变量
不同的设置更好的对于服务器的light， 可预测的负载,
服务器运行的所有的时间,或者高活动的。
因为InnoDB 存储引擎执行很多的自动优化, 很多的性能调优的任务设计监控来确保数据库是表现良好的
改变配置选项 当性能下降时。 See Section 14.13, “InnoDB Integration with MySQL Performance Schema” for
information about detailed InnoDB performance monitoring.
主要的配置步骤你能执行包括:
启用InnoDB 使用 high-performance memory 分配在系统
See Section 14.3.4, “Configuring the Memory Allocator for InnoDB”.
控制DML 操作的类型,以避免频繁的小的磁盘写。See Section 14.3.5, “Configuring InnoDB Change Buffering”.
因为 默认是Buffer 所有类型的DML操作,
改变这个设置 如果你需要降低buffer的总量
调优自适应的hash indexing feature 和 关闭使用innodb_adaptive_hash_index option.
设置一个限制并发threads ，如果上下文切换是一个瓶颈。
控制预取的总量,Innodb 使用的预读操作。
当系统有没有使用的I/O 容量, 可以提高查询的性能。 太多的预读可能会导致性能降低
增加后台threads 的数量用于读写操作,如果你有一个高端的I/O子系统
没有完全利用的在默认情况下
控制多少个I/O INNODB 执行在后台See Section 14.3.8, “Configuring the InnoDB Master Thread I/O Rate”.
后台I/O 的总量是比MySQL 5.1高,因此你可能需要缩减这个设置
控制算法 确定当InnoDB 执行某种类型的后台写。
See Section 14.3.3.2, “Configuring the Rate of InnoDB Buffer Pool Flushing”
这种算法适用于某些工作负载,但不是其他的,所以可能关闭此设置，如果你观察到定期下降的表现。
利用多核处理器和它们的cache memory 配置,最大限度减少上下文切换
调整log files 到一个大小,使可靠性和crash recovery 变的有意义。
InnoDB log files 通常都是小的来避免长时间的启动在一个crash后
优化在 MySQL 5.5.4介绍来加速crash recovery 处理的某些步骤。
特别的,扫描redo log ，应用redo log 更快由于改进的算法(内存管理)
如果你已经保持你的Log files 人为的小来避免启动时间过长,
你可以考虑增加log file size 来避免I/O,由于循环的redo log 记录
配置InnoDB buffer pool 的数量和大小,尤其是对于multi-gigabyte buffer pools. See Section 14.3.3.4, “Using
Multiple Buffer Pool Instances”.