Mysql二进制日志缓存参数：
binlog_cache_size //事务缓存大小
binlog_cahce_use //事务缓存使用次数
binblog_cache_disk_use //事务缓存磁盘使用次数（内存缓存设置过小不够用时）
binlog_stmt_cache_size //非事务语句缓存大小
binlog_stmt_cache_use //非事务语句缓存使用次数
binlog_stmt_cache_disk_use //非事务语句磁盘缓存使用次数
我们知道InnoDB存储引擎是支持事务的。实现事务需要依赖日志技术，为了性能，日志编码采用二进制格式。
那么，我们何时记录日志呢？有日志的时候就直接写入磁盘？但因为磁盘的效率是很低的，如果你用过Nginx，一般Nginx输出access log都是要缓冲输出的。因此，记录二进制日志的时候，我们也需要考虑使用内存缓存。但由于缓存不是直接持久化，所以面临着系统宕机时不能及时刷入磁盘的安全问题。因此，Cache需要权衡，既减少磁盘I/O，满足性能的要求；又尽可能保证内存缓存中没有残留，及时的持久化，满足安全要求。
参数 binlog_cache_size 就是用来控制它的，一个事务在没有提交（uncommitted）的时候，产生的日志，记录到Cache中；等到事务提交（committed）需要提交的时候，则把日志持久化到磁盘。需要注意的是：binlog_cache不是全局的，而是以SESSION为单位独享分配的，也就是说当一个线程开始一个事务的时候，Mysql就会为这个SESSION分配一个binlog_cache。系统默认的 binlog_cache_size 只有32k。当我们提交一个长事务的时候，比如批量导入数据，而cache里面放不下的时候，mysql就会把已经提交的事务记录到一个临时文件中，等提交时再刷入日志，但临时文件的性能明显要比内存低。固其大小需要权衡，查看当前cache的大小使用：
mysql> show session variables like ‘binlog_cache%‘;
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| binlog_cache_size | 67108864 |
+-------------------+----------+
1 row in set (0.00 sec)
查看全局cache大小：
mysql> show global variables like ‘binlog_cache%‘;
+-------------------+----------+
| Variable_name | Value |
+-------------------+----------+
| binlog_cache_size | 67108864 |
+-------------------+----------+
1 row in set (0.00 sec)
查看配置文件：
grep ‘binlog_cache‘ /etc/my.cnf
binlog_cache_size = 64M #系统默认配置大小
max_binlog_cache_size = 128M
max_binlog_size = 200
查看该值是否满足需要：
show status like "binlog_%";
+-------------------------+-------------+
| Variable_name | Value |
+-------------------------+-------------+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 120402264 |
+-------------------------+-------------+
2 rows in set (0.00 sec)
binlog_cache_disk_use表示缓存超出时，使用磁盘临时文件的次数，为0表示没使用过，所以当前cache size够用。如果没有长事务long_trascation的话，则表示该值偏大。
binlog_stmt_cache_size与binlog_cache_size类似，与之相对的是binlog_stmt_cache_disk_use。