选择合适的innodb_log_file_size

核心提示： 首先，让我先来解释一下恢复时都发生了什么事情以及为什么设置 innodb_log_file_size 的值太大了会让恢复过程变慢，选择合适的innodb_log_file_size(2)，Innodb 数据表崩溃再次启动时，MySQL 会扫描日志文件来找到那个只应用到内存中并且不存在的表空

首先，让我先来解释一下恢复时都发生了什么事情以及为什么设置 innodb_log_file_size 的值太大了会让恢复过程变慢。Innodb 数据表崩溃再次启动时，MySQL 会扫描日志文件来找到那个只应用到内存中并且不存在的表空间的日志记录。那些没有没有放到表空间的修改日志记录就要被加进去。这叫做重做相位恢复。这需要相当长时间，它取决于变量的值 -- 到底有多少行记录？(日志记录的值越小意味着同样大小的日志里可以存储更多的记录)，随机数据修改的几率有多高(随机更新需要有更多的随机IO来检查内存页是否更新)，innodb 缓冲池中未被刷新的内存页数量并且它也是IO子系统的性能表现。由于有这么多因素，就很难产生通用的准绳，例如每10分钟恢复1GB数据的时长 -- 相反地，应该在典型的应用中来确定负载，在MySQL崩溃的过程中来监查它是怎么恢复的。这么做几次之后，你就应该能大致估算恢复所需的时间了从而更恰当地调整日志大小。好事是 -- 重做相位和日志文件大小成正比，因此预计恢复1GB的日志所需的时间大致是512MB的2倍。

Redo phase is however only one of the phases of recovery. The other important one is undophase - after log file are applied and database is in “physically consistent” state, Innodb will need to roll back certain transactions which Where not commited, but changes from which already made it to the database. Unlike “redo” phase “undo” phase can’t be reduced by sizing your log files. Even more undo phase can be slower with small log files. Undo phase takes considerable time if tranactions are long - Ie if you would delete 10000000 rows in the same transaction and crash in the middle recovery can take quite a long time. The only way you can reduce “undo” phase is size your transactions appropriately - so updates/inserts/deletes can be sized to affect limited number of rows.