前面的壓測報告中最有趣的一張圖莫過于這張波浪圖了
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張表過來，數據量非常?。?/p>
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年后的今天翻起來才發現這篇筆記沒有寫完，但是當初的壓力測試環境已經沒有了，因此沒有辦法對當初的那張測試圖形進行很好的跟蹤，有點遺憾
