append 写日志的方式是不是很容易退化为随机IO

Question

像 mysql 这类要保证断电防丢的数据库，为了同时兼顾性能，不会每次要写入数据都把数据写入到硬盘该有的位置，而是写入到一个 log 文件里面（redo、undo之类的）。

计算机中跑着很多进程，除了mysql相关的，可能还有kafka、hbase、hdfs等等都会时时刻刻要写硬盘。那这个时候以 write append log 顺序写日志的方式其实也变成了一种随机的IO呀。

比如说，这一刻，mysql要写一个数据，向他自己的log先追加1k 的数据，然后下一毫秒，hbase要写写入数据了，让要给自己的日志append 1k 的内容，这个时候硬盘的磁头就要去旋转了呀，这不就退化变成了随机IO了吗？

所以计算机中跑着大量要写硬盘的进程的情况下，即便采用 append 写日志其性能也应该非常差吧！

要解决这个问题，是不是最好让电脑写硬盘的进程尽可能少，出了必要的系统进程之外最好不要有其他写硬盘进程。

举一个例子：
比如MySQL收到了一个 insert 请求
他就必须立刻马上写硬盘
即便数据只有1个字节
但是这个时候硬盘正在处理其他任务
硬盘就要立刻马上旋转磁头来处理mysql的任务
下一纳秒，hbase要写入一个1字节的数据
下两纳秒，gfs要写入1字节的数据
这个时候
虽然从mysql、hbase、gfs的角度是顺序（顺序写log）
但是从硬盘的角度就是随机io
实际速度还是超级拉跨的随机IO速度

Answer 1

顺序I/O是针对单个文件；你要从有多个进程写不同的文件这个层面上看，那确实是随机I/O了。

所以有条件上固态，没条件也尽量别 MySql 和其他需要硬盘的服务部署在一起。

当然还是看最后的业务需要，要是拢共没多少数据量也就无所谓了。