8.5.8 Optimizing InnoDB Disk IO 优化InnoDB Disk I/O
如果你遵循最佳实践对于数据库的设计和调优技术对于SQL操作,
但是你的数据库仍旧是很慢的 由于沉重的disk I/O 活动,
探索这些low-level 技术相关的disk I/O
如果unix top攻击或者Windows Task Manager 显示CPU 使用率是小于70%,你的workload 可能是磁盘。
当表中的数据是cache在InnoDB buffer pool，它可以通过查询不需要任何的disk I/O
指定buffer pool的大小使用innodb_buffer_pool_size
这个内存的区域是很重要的 对于繁忙的数据 通常指定物理内存的80%
在一些Linux 或者Unix 的一些版本, flush 文件到磁盘使用Unix的 fsync() call( InnoDB 默认使用）
类似的方法是出奇的慢,如果数据库写性能是一个问题,innodb_flush_method parameter set to O_DSYNC.
当使用 InnoDB 存储引擎在 Solaris 10 for x86_64 architecture (AMD Opteron),
使用direct I/O用于 InnoDB-related files,为了避免InnoDB 性能恶化。
使用direct I/O 对于一个UFS 文件系统用于存储InnoDB-related files,
挂载它用 forcedirectio option
当使用InnoDB 存储引擎 设置一个大的innodb_buffer_pool_size的值在任何的 Solaris 2.6版本上
和任何其他的平台,
InnoDB 数据文件和Log files 在裸设备上或者一个单独的I/O UFS 文件系统
不要放其他的MySQL 数据文件, 比如 MyISAM 表,
在一个direct I/O 文件系统。可执行文件或者库不用放在direct I/O 文件系统
如果你有额外的存储设备 来配置一个RAID 配置或者 符号连接到不同的磁盘Section 8.12.3, “Optimizing Disk I/O” for
additional low-level I/O tips.
如果吞吐量下降因为InnoDB 检查点操作 ,考虑增加 innodb_io_capacity configuration option.
更高的值可以导致更频繁的flush，避免积压,这可能会造成吞吐量下降