前面的压测报告中最有趣的一张图莫过于这张波浪图了
TPS一次次的冲向波峰，然而没能持续多久就被拖到波谷，这个曲线对应的参数是innodb_log_file_size=100M
提取log查看当时的测试值
当该参数取1G和4G时的TPS则几乎一致，而取值100M的时候tps出现了明显的波动
当log_file_size取值太小时会有什么危害？
当一个日志文件写满后，innodb会自动切换到另外一个日志文件，而且会触发数据库的检查点（Checkpoint），这会导致innodb缓存脏页的小批量刷新，会明显降低innodb的性能。由于日志切换更频繁，也就直接导致更多的BUFFER FLUSH，由于日志切换的时候是不能BUFFER FLUSH的， BUFFER写不下去，导致没有多余的buffer 写redo， 那么整个MYSQL就HANG住，还有一种情况是如果有一个大的事务，把所有的日志文件写满了，还没有写完，这样就会导致日志不能切换（因为实例恢复还需要，不能被循环复写）这样mysql就hang住了
#2019.7.9补充
Innodb_log_file_size的取值
通常的做法是在高峰期算出MySQL在1分钟内产生的log量，然后估算出1小时的log量然后除以log组的组员数量，得到的便是Innodb_log_file_size值
对于Innodb_log_file_size过大的担心，主要在于recovery过程太久，但Innodb_log_file_size的值并不是recovery的唯一决定因素
log一小时的量计算方法
#测试的是一个线上库的从库（只过滤了26张表过来，数据量非常小）
pager grep sequence
#PAGER set to 'grep sequence'
show engine innodb status \G select sleep(60);show engine innodb status \G
#Log sequence number 719175320085
#1 row in set (0.00 sec)
#1 row in set (1 min 0.00 sec)
#Log sequence number 719175446230
#1 row in set (0.00 sec)
select (719175446230-719175320085) /1024 /1024 as MB_per_min;
+------------+
| MB_per_min |
+------------+
| 0.12030125 |
+------------+
1 row in set (0.00 sec)
可以看到，当前系统1分钟产生的log量约为0.12M，换算成1小时也不过7M左右，log组成员为3，算下来innodb_log_file_size也就是2.4M，对于这套系统，设置innodb_log_file_size=4M足以
备注
文章写于18年5月，之后便遗忘了，1年后的今天翻起来才发现这篇笔记没有写完，但是当初的压力测试环境已经没有了，因此没有办法对当初的那张测试图形进行很好的跟踪，有点遗憾
