从数据库层面理解：随机 I/O & 顺序 I/O

在 谈这俩概念前、先来说说 大I/O vs. 小I/O 通常、我们把 =16KB 的I/O认为是小I/O、而 =32KB 的I/O认为是大I/O 了解I/O的大

在谈这俩概念前、先来说说 大I/O vs. 小I/O
     通常、我们把 <=16KB 的I/O认为是小I/O、而 >=32KB 的I/O认为是大I/O
     了解I/O的大小、影响到后期对缓存、RAID类型、LUN的一些属性的调优
    
     当前大多数数据库使用的都是传统的机械磁盘
     因此、整个系统设计要尽可能顺序I/O
     避免昂贵的寻道时间和旋转延迟的开销
     随机小I/O消耗比顺序大I/O更多的处理资源
     随机小I/O更在意系统处理I/O的数量、即IOPS、比如、OLTP
     而顺序大I/O则更在意带宽、即MB/s、比如、OLAP
     因此、如果系统承载了多种不同的应用
     必须了解它们各自的需求、是对IOPS有要求、还是对带宽有要求

    

     传统机械磁盘最大的问题在于读写磁头

     读写磁头的存在可以让磁盘既能顺序I/O、也可随机I/O

     但是、随机I/O需要花费昂贵的磁头旋转和定位来查找

     因此、顺序IO访问的速度远远快于随机IO

     数据库的很多设计也都是尽量充分利用顺序IO、比如Oracle REDO LOG写便是顺序IO

     如果、数据库服务器同时使用顺序和随机I/O、随机I/O从缓存中受益最多
     原因有 3 ：
     ① 顺序I/O一般只需扫描一次数据、所以、缓存对它用处不大
     ② 顺序I/O比随机I/O快
     ③ 随机I/O通常只要查找特定的行、但I/O的粒度是页级的、其中大部分是浪费的
          而、顺序I/O所读取的数据、通常发生在想要的数据块上的所有行
          更加符合成本效益
     所以、缓存随机I/O可以节省更多的workload
       
     传统的数据库架构对随机IO几乎没有还手之力、随机IO几乎令所有DBA谈虎色变
     而聪明如MySQL InnoDB 则利用事务日志把随机I/O转成顺序I/O
     窃以为、如果能负担得起、增加内存是解决随机I/O最好的办法