1.innodb_log_file_size
1）作用：参数决定着mysql事务日志文件（ib_logfile0）的大小，和innodb_log_files_in_group参数相关，innodb_log_files_in_group参数控制日志文件数。默认值为2。mysql 事务日志文件是循环覆写的。
2）默认值：48M
3）最大可以设置：512GB / innodb_log_files_in_group 几个group相乘不可以超过512GB
4）设置依据：当写很大，然后每分钟的redo log值很大，需要增加该值， 一般来说，日志文件的合并大小应该足够大，以便服务器能够平滑工作负载活动的高峰和低谷，
这通常意味着有足够的重做日志空间来处理超过一个小时的写活动。值越 大，缓冲池中需要的检查点刷新活动就越少，从而节省磁盘I/O。更大 的日志文件也会使崩溃恢复变慢。
5）如何判断一个小时的redo log量：
pager grep Log ##使用page之后，执行的命令只显示 Log开头的
show engine innodb statusG select sleep(60); show engine innodb statusG;
Log sequence number 4578059050533
Log flushed up to 1149269980149
1 row in set (0.00 sec)
Log sequence number 4578062739081
Log flushed up to 1149270019005
1 row in set (0.00 sec)
MariaDB [(none)]> nopager
PAGER set to stdout
MariaDB [(none)]> select (4578062739081-4578059050533)/1024/1024 as MB;
得出的值为一分钟的redo log * 60就是一个小时的量， 通过计算后得到每分钟有3.5M的日志写入。
根据经验法则。通常我们设置redo log size足够大，能够容纳1个小时的日志写入量。
1小时日志写入量=3.5M * 60=210M，由于默认有两个日志重做日志文件ib_logfile0和ib_logfile1。在日志组中的每个重做日志文件的大小一致，并以循环的方式写入。
innodb存储引擎先写重做日志文件0，当达到文件的最后时，会切换到重做 日志1，并checkpoint。以此循环。
所以我们可以大约设置innodb_log_file_size=110M。
6） 设置不合理的影响：
7） 设置的太小：当一个日志文件写满后，innodb会自动切换到另外一个日志文件，而且会触发数据库的检查点（Checkpoint），这会导致innodb缓存脏页的小批量刷新，会明显降低innodb的性能。由于日志切换更频繁，
也就直接导致更多的 BUFFER FLUSH，由于日志切换的时候是不能BUFFER FLUSH的， BUFFER写不下去，导致没有多余的buffer 写redo， 那么整个MYSQL就HANG住，还有一种情况是如果有一个大的事务，
把所有的日志文件写满了，还没有写完，这样就会导致日志不能切换（因为实例恢复还需要，不能被循环复写）这样mysql就hang住了。可以根据文件修改时间来判断日志文件的旋转频率，旋转频率太频繁，说明日志文件太小了。
设置的太大：设置很大以后减少了checkpoint，并且由于redo log是顺序I/O，大大提高了I/O性能。但是如果数据库意外出现了问题，比如意外宕机，那么需要重放日志并且恢复已经提交的事务
（也就是实例恢复中的前滚, 利用redo从演变化 来恢复buffer cache中的数据），如果日志很大，那么将会导致恢复时间很长。甚至到我们不能接受的程度。
8） 调整方法：
无法在线修改，需要重启数据库
1.修改配置文件
innodb_log_file_size=100M
2.备份原来ib_logfile文件，并删除原来的
3.重启数据库，会新建ib_logfile文件
9）相关配置参数：
innodb_log_buffer_size 默认16M，
生产建议：和innodb_log_file_size有关，1-N倍