redo log增大换取更稳定的性能，代价是故障恢复时间变长

MySQL的innodb_log_file_size（redo log大小）参数上限在版本演进中大幅提升——5.6.2版本之前最大只能设置4GB，5.6.2版本之后最大可以设置到512GB，这为调优提供了新的空间。但更大的redo log不是越大越好，而是一个需要认真权衡的取舍：理论上更大的redo log能带来更稳定的性能表现（减少因为redo log写满而触发的检查点刷盘等操作对性能造成的抖动），但这份稳定性是有代价的——一旦数据库真的发生故障需要恢复，更大的redo log意味着崩溃恢复（crash recovery）过程需要重放的日志量也更大，故障恢复所需要的时间会相应变长。这个案例给出了一条评估数据库参数调优的重要原则：几乎所有看起来”越大越好”的容量类参数，背后都隐藏着与之对应的代价，这个代价往往不会在日常运行时表现出来，而是只有在真正触发某种边界场景（这里是故障恢复）时才会显现——评估这类参数时，不能只看它在正常运行状态下带来的收益（这里是性能更稳定），还必须同时评估它在异常场景下带来的代价（这里是恢复时间变长），并且要结合自己业务对”故障恢复时间”这个指标的真实容忍度来做决策：如果业务对RTO（恢复时间目标）要求极其严格，一味追求更大redo log换取的运行时稳定性可能得不偿失；如果业务能够容忍相对较长的故障恢复窗口，那么更大的redo log换取更平稳的日常性能表现就是合理的取舍。