innodb磁盘IO优化

　　如果你的数据库的设计和sql语句已经没有办法进行优化，但你的数据库仍然被大量的磁盘IO拖的很慢，那么你应该试试优化磁盘ＩＯ；使用Unix的top工具或者windows的任务管理器可以查看CPU的使用情况，如果你的CPU的负载在70%以下，那么可能是出现了磁盘瓶颈。你可以通过下面的方式进行优化：
　　　　1. 设置恰当的innodb_buffer_pool_size值；当数据被缓存在innodb数据缓冲区是，它可以不用请求任何的磁盘IO而进行重复的访问。
　　　　2. 如果你的数据库写性能存在问题，可以通过设置参数innodb_flush_method为O_DIRECT。这是由于在一些版本的GNU/Linux和Linux中，刷数据到磁盘调用的方法是fsync()，而innodb默认也使用这个；这个类似的方法是出奇的慢。
　　　　3. 如果你有多个存储设备可以用，可以配置RAID阵列或者符号连接到不同的磁盘。符号链接优化innodb磁盘IO的原理：通过符号链接到不同的磁盘从而增加磁盘主轴的可用数量。对MyIsam表来说，可以给数据目录中的将数据文件和索引文件建立符号链接到其它磁盘。这可以让寻道时间和读取数据的的时间更快；前提是该磁盘不能用做其它用途。对innodb表，innodb符号链接不支持；但是如果你开启了独立表空间后，你可以使用create table语句中的data directory子句指定表空间到数据目录之外的其它目录中（如果目录挂载其它磁盘则可分担IO）。
　　　　4. 如果由于innodb checkpoint的原因，吞吐量定期下滑，可以考虑增加参数 innodb_io_capacity的值；更高的值可以让flush操作更频繁，这样可以避免由于工作量的积压而造成的吞吐量下降。但是从参数值也不能太高，最好的情形是：保持该值尽量低，但又不要低到出现前面提到的吞吐量的周期性下滑。由于innodb_io_capacity参数表示的总的IO能力的上限，其中包括buffer pool，insert buffer，log buffer的数据刷到磁盘时的IO，所以此参数的的值是否过大可以通过这几个地方的脏页的数量和各自总大小的百分比来判断，可以通过show engine innodb status来查看需要的信息：
　　　　　　• buffer pool中modified pages的数量远小于innodb_max_dirty_pages_pct。（在非批量插入时）
　　　　　　• insert buffer中的merges接近insert的数量
　　　　　　• Log sequence number减去Last checkpoint的值小于日志文件的7/8（最好3/4）；
　　　　　　• History list length小于几千（undo表空间里页面的数目，如果页面执行了更新或提交，此数值会增加，当purge线程清楚旧数据时又会减少）；
　　　　5.如果使用了innodb的压缩特性，当压缩数据发生变化时，在redo log中存储的是将页进行重新压缩；这是为了防止在恢复时会用到不同版本的zlib压缩算法而导致数据损坏。如果你确认zlib的版本不会发生变化，可以将参数innodb_log_compressed_pages设置为off，这样可以减少在修改压缩数据时redo log的产生。