mysql分组提交和实时fsync

核心提示： 第一个问题可以查看 这个bug，概括地说，mysql分组提交和实时fsync(2)，这个问题是新特性 -- MySQL 5.0 中新增加了 XA 特性，它不支持旧的分组提交代码，性能会被降低，不过这会越来越少，然而新的分组提交代码还完全没实现，XA 支持让不同的事务性存储引擎保持同步

第一个问题可以查看 这个bug。概括地说，这个问题是新特性 -- MySQL 5.0 中新增加了 XA 特性，它不支持旧的分组提交代码。然而新的分组提交代码还完全没实现。XA 支持让不同的事务性存储引擎保持同步，都保存在二进制日志中。如果启用了二进制日志，则 XA 也启用了，这就是为什么启用二进制日之后会触发这个问题。如果禁用二进制日志，则 XA 和旧的分组提交代码就都没问题了。

Second one is interesting. Actually we would hear much more people screaming about this problem if OS would be honest with us. Happily for us many OS/Hardware pairs are still lying about fsync(). fsync() call suppose to place data on the disk securely, which unless you have battery backed up cache would give you only 80-200 sequential fsync() calls per second depending on your hard drive speed. With fake fsync() call the data is only written to the drives memory and so can be lost if power goes down. However it gives great performance improvement and you might see 1000+ of fsync() calls per second. So if your OS is not giving you real fsync you might not notice this bug. The performance degradation will still happen but it will be much smaller, especially with large transactions.

第二个问题很有趣。事实上如果操作系统更加诚实的话，我们将会听到更多的用户的抱怨。幸好，对我们来说，不少操作系统/硬件组合还是基于 fsync() 之上。fsync() 调用假使安全地把数据放在磁盘中，除非有备用电池高速缓存依赖于磁盘的驱动速度才只能达到每秒 80 - 200 次连续的 fsync() 调用。而伪 fsync() 则只是把数据写在磁盘内存中，一旦断电了，这些数据就会丢失了。不过这么做能获得很高性能，大约能达到每秒有1000多次的 fsync() 调用。因此，如果你的操作系统不支持实时 fsync() 调用，就要注意这个bug。性能会被降低，不过这会越来越少，尤其是在很大的事务过程中。