面试题：MySQL存储引擎特性对MTTR的影响及优化

InnoDB：
- 日志机制：InnoDB 使用redo log（重做日志）和undo log（回滚日志）。Redo log 用于崩溃恢复（crash - recovery），记录了数据库物理层面的修改操作，保证在发生崩溃后可以恢复到崩溃前的状态。Undo log 用于事务回滚以及一致性读。
- 事务支持：支持事务，崩溃恢复时能保证事务的原子性和持久性。对于未完成的事务，利用undo log回滚；对于已提交的事务，利用redo log重放。
MyISAM：
- 无事务日志：MyISAM 不支持事务，没有redo log和undo log。在发生故障时，MyISAM 通常需要进行全表扫描来恢复数据，例如在数据库崩溃后，MyISAM 表可能需要通过备份进行恢复，或者使用 myisamchk 工具进行修复。

InnoDB适用场景及优化：
- 场景：适用于对事务完整性要求高、并发读写操作频繁的业务场景，如电商交易、银行转账等。
- 优化措施：
  - 合理配置redo log参数：如 innodb_log_file_size 和 innodb_log_files_in_group。增大 innodb_log_file_size 可以减少日志切换频率，但会增加恢复时间，需根据实际业务调整。
  - 调整checkpoint机制：InnoDB 通过checkpoint将部分脏页写回磁盘，合理调整 innodb_max_dirty_pages_pct 等参数，控制脏页比例，减少崩溃恢复时需要重放的redo log量。
MyISAM适用场景及优化：
- 场景：适用于读操作远多于写操作，对事务要求不高的场景，如博客系统、简单的新闻发布系统等。
- 优化措施：
  - 定期备份：由于没有事务日志，定期备份数据至关重要，可使用 mysqldump 等工具进行备份，以便在故障后快速恢复。
  - 使用 myisamchk 工具：定期使用 myisamchk -r 对表进行修复和优化，提前发现并解决潜在问题。

InnoDB优化挑战及解决方案：
- 挑战：
  - redo log配置不当：若 innodb_log_file_size 过小，日志切换频繁影响性能；过大则恢复时间长。
  - checkpoint设置不合理：若 innodb_max_dirty_pages_pct 设置过高，可能导致崩溃恢复时需要重放大量redo log；过低则会频繁刷盘影响性能。
- 解决方案：
  - 性能测试：通过模拟实际业务负载，进行性能测试，找到 innodb_log_file_size 和 innodb_max_dirty_pages_pct 的最优值。
  - 监控与调整：利用 SHOW ENGINE INNODB STATUS 等命令监控InnoDB运行状态，根据实际情况动态调整参数。
MyISAM优化挑战及解决方案：
- 挑战：
  - 备份恢复时间长：全量备份恢复数据时间长，影响业务恢复。
  - 表损坏风险：MyISAM表在系统崩溃或硬件故障时容易损坏。
- 解决方案：
  - 增量备份：结合全量备份进行增量备份，减少恢复时间。例如，利用二进制日志（binlog）实现增量恢复。
  - 硬件监控与冗余：监控硬件状态，采用RAID等冗余技术，降低硬件故障导致表损坏的风险。

知识考点