谈谈分布式事务之一：SOA需要怎样的事务控制方式

如果对 Innodb 数据表有大量的写入操作，那么选择合适的 innodb_log_file_size 值对提升MySQL性能很重要。然而设置太大了，就会增加恢复的时间，因此在MySQL崩溃或者突然断电等情况会令MySQL服务器花很长时间来恢复。

那么，怎么才能找到最佳的配置组合呢？

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

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

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

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

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