目前web的应用大多都以I/O密集型为主，而存储技术的发展远没有计算机中其他系统发展迅速，尽管也有不少高端存储设备，但是价格的昂贵，不是一 般大众能享受的起的。而基于现状更多是我们使用一般SAS盘结合应用使用不同的RAID组合，来实现我们平民化存储，为了得到更好的性能，那么和I/O相 关的调整优化是必不可少的。　　对于我们数据库调优来说，磁盘I/O优化是首屈一指的调优重点，我们都知道木桶原理，短板绝对整体的好坏， 而数据库系统中这个短板正是由于我们使用的硬件设备里最弱的磁盘所导致。很多时候，我们会发现系统中I/O累得要死，而CPU却在那里空闲等待，主要是由 于I/O执行响应时间太长，处理读写的速度远远赶落后于CPU的处理速度，这时我们会尽可能的让操作放到内存中进行，由磁盘与CPU的关系，转变成内存与 CPU的关系。但是，我们始终不能回避磁盘I/O的弱点，优化是必须的。
　　对于数据库在日常应用中的特点，我们可以有很多想法。
　　1. 随机读写的负载可以通过增加硬盘的个数实现扩展。
　　2. 对于顺序读写带来的压力，可以通过选择带宽相对高一些的磁盘来解决。
　　3. RAID 5和RAID 10都是不错的原则对于数据库应用来说。
　　4. 当然，基于自身业务的关键程度与成本双重考虑，Fusion-io卡(读与写的性能俱佳)和SSD(优秀的随机读)，都未尝不是一个理想的选择。
　　5. 在操作系统中，I/O Scheduler的调度模式选择deadline对于数据库应用是有利的。命令：echo deadline > /sys/block//queue/scheduler
　 　6. 操作系统中nr_requests参数，可以提高系统的吞吐量，似乎越大越好，但是该请求队列的也不能过大，因为这样会消耗大量的内存空间。该值的调整需 要综合多处因素，比如： 文件系统、sheduler类型、io的特点。命令： echo xxx > /sys/block//queue/nr_requests，nr_requests的大小设置至少是/sys/block//device /queue_depth的两倍，所以，修改nr_requtests的时候要注意。
　　7. 系统目录/sys/block//queue下还有一个预读的参数read_ahead_kb，这个参数增大只会对顺序读的操作有提升，而数据库这类应用中多数是随机读;通过命令hdparm -t /dev/sda{,,}可以测试修改后预读的效果。