简单说说DOUBLE WRITE和块断裂

说白了，Oracle就像当今老美防疫一样，靠着自己的医疗资源高端硬抗，大不了老子弄20万张ICU床位出来，
这一点
别人学不来。Mysql等开源数据库都无法像Oracle一样依赖高端的硬件来避免大多数的问题，于是采用DOUBLE WRITE BUFFER的机制来避免块断裂。原理比较简单，就是在数据块写入数据文件之前，先把这个数据块写入到一个文件缓冲区中（不是内存，是文件，在一个独立的文件区域中开一个2M的缓冲，用于写入最近的数据块），然后再写入真的文件。这样做就能够有效的避免块断裂了，如果写入缓冲出错，没关系，真实的文件还没写呢；如果写真实文件的时候出问题了，那么到DOUBLE WRITE BUFFER中去找到这个块来恢复就行了。很完美的解决方案，不过这里就有一个代价，所有缓冲区写入文件都要写两遍，这会带来巨大的IO开销。当然DOUBLE WRITE BUFFER的写入是顺序写，比随机写开销小很多，不过这部分开销对于大并发量的系统来说，还是不小的开销。

实际上，很多数据库都有类似的机制来解决块断裂的问题，华为Gaussdb 100也有类似的double write buffer（自动存放于system表空间中）；PostgreSQL是依靠暴力的把整块数据页写入WAL来解决这个问题的，这会导致WAL暴涨，因此有些用户通过采用WAL压缩来解决这个问题，也有人写了一个插件，在PG中实现类似MYSQL的DOUBLE WRITE BUFFER的机制来替代整个页面写入WAL。现在也有不少从数据库到OS到硬件的整体解决方案，来实现写原子化或者通过文件系统的写日志保证写事务可回滚，从而避免块断裂的问题（最典型的是ZFS）。如果的MYSQL之类的跑在这样的系统上，那么你不打开DOUBLE WRITE BUFFER也是没问题的。

其实解决这个问题不难，而且有许多种渠道，除了OS与文件系统支持原子写操作外，如果你的数据库本身就是高可用的，比如有类似oracle adg，mysql半同步复制集群之类的机制，那么你就不需要打开double write buffer了。

另外一个思路是把double write buffer变成独立的文件，这样就可以把这个文件放在一个比较快的独立设备上了（比如放到INTEL 傲腾内存盘上）。不过目前MYSQL,高斯等好像还不支持独立放置，只能放在系统表空间中。