选择合适的innodb_log_file_size

核心提示： 然而重做相位是相位恢复的唯一方法，另一个重要的方法是撤销相位 -- 当日志文件应用完之后并且数据库处于 "物理一致性" 状态时，选择合适的innodb_log_file_size(3)，Innodb 会回滚那些没提交的事务，但是已经对数据库所做的修改就不管了，Note

然而重做相位是相位恢复的唯一方法。另一个重要的方法是撤销相位 -- 当日志文件应用完之后并且数据库处于 "物理一致性" 状态时，Innodb 会回滚那些没提交的事务，但是已经对数据库所做的修改就不管了。不像 "重做" 相位，"撤销" 相位不会因为日志尺寸变小而变快。甚至撤销相位还可能因为日志较小而变慢。撤销相位所耗时间因事务长短所致 -- 例如，如果需要在一个事务中删除 10000000 行记录，这个事务中途发生错误崩溃了，那么恢复就需要花很长时间了。唯一能减少 "撤销" 相位的方法是设置适当的日志大小值 -- 这样的话，记录更新/插入/删除时就会被限定在有限的数量里了。

Good thing about updo phase however is - it can be done in background as in MySQL 5.0. The rows affected by background rollback however might not be modified until rollback is complete.

不过撤销相位的好处是 -- 在MySQL 5.0中，它可以让在后台来执行。后台回滚的记录直至恢复完之后才能被修改。

One more thing to consider - how large log files do you need at all ? You could run benchmark with 1GB log files and 2GB and see if there is any performance benefit. After certain size increasing log file size do not dramatically increase performance, however this again depends on configuration and workload.

另一个要考虑的事是 -- 到底需要多大的日志？可以运行基准测试来检查 1GB 大小的日志相对 2GB 有什么好处。日志文件增加到一定大小后未必会戏剧性地提高性能，然而这同样依赖于配置以及MySQL的工作负载。

Note at this poing 4GB is maximum combined size allowed for innodb log files, which is however large enough limit for most onfigurations.

注意，这里举例中的 4GB 是 innodb 日志文件的最大值，不过它明显比常用的配置大得多了。