mysql max_binlog_cache_size_MySQL binlog cache详解

最近在线上遇到一个突发情况：某客户出现了超大事务，该事务运行时占据的磁盘空间超过800GB，但du -sh时未发现任何线索。于是刨根溯源，找到了最终的原因并紧急处理了该问题。本文便是对该问题涉及的binlog cache知识进行整理，希望也能造福更多的朋友。本文会涉及到如下几个概念：binlog cache：它是用于缓存binlog event的内存，大小由binlog_cache_size控制

binlog cache 临时文件：是一个临时磁盘文件，存储由于binlog cache不足溢出的binlog event，该文件名字由"ML"打头，由参数max_binlog_cache_size控制该文件大小

binlog file：代表binglog 文件，由max_binlog_size指定大小。

binlog event：代表binlog中的记录，如MAP_EVENT/QUERY EVENT/XID EVENT/WRITE EVENT等。

事务binlog event写入流程

binlog cache和binlog临时文件都是在事务运行过程中写入，一旦事务提交，binlog cache和binlog临时文件都会释放掉。而且如果事务中包含多个DML语句，他们共享binlog cache和binlog 临时文件。整个binlog写入流程如下：1. 事务开启

2. 执行dml语句，在dml语句第一次执行的时候会分配内存空间binlog cache

3. 执行dml语句期间生成的event不断写入到binlog cache

4. 如果binlog cache的空间已经满了，则将binlog cache的数据写入到binlog临时文件，同时清空binlog cache。如果binlog临时文件的大小大于了max_binlog_cache_size的设置则抛错ERROR 1197

5. 事务提交，整个binlog cache和binlog临时文件数据全部写入到binlog file中，同时释放binlog cache和binlog临时文件。但是注意此时binlog cache的内存空间会被保留以供THD上的下一个事务使用，但是binlog临时文件被截断为0，保留文件描述符。其实也就是IO_CACHE(参考后文)保留，并且保留IO_CACHE中的分配的内存空间，和物理文件描述符

6. 客户端断开连接，这个过程会释放IO_CACHE同时释放其持有的binlog cache内存空间以及持有的binlog 临时文件。