MyISAM 引擎完全不使用 Redo Log，因其不支持事务和崩溃恢复，无 Buffer Pool 与脏页机制，修改直接写磁盘；所有 InnoDB 日志参数对其无效，其一致性依赖手动修复而非日志重放。
Redo Log 根本不作用于 MyISAM 引擎
MyISAM 完全没有 Redo Log。它既不生成、也不使用 ib_logfile0 或 ib_logfile1 这类文件，innodb_flush_log_at_trx_commit 参数对 MyISAM 表无效，任何针对 Redo Log 的配置（如 innodb_log_file_size）也只影响 InnoDB。
为什么 MyISAM 不需要 Redo Log
Redo Log 是 WAL（Write-Ahead Logging）机制的产物，而 WAL 的前提是支持事务和崩溃恢复——MyISAM 全都不具备：
- MyISAM 不支持事务，
BEGIN/COMMIT对它无意义，自然不需要“保证已提交事务不丢” - MyISAM 修改数据是直接写磁盘（.MYD 文件），没有 Buffer Pool + 脏页异步刷盘这一层，也就没有“内存已改、磁盘未写”的风险场景
- 崩溃后 MyISAM 无法自动恢复一致性，只能靠
REPAIR TABLE或myisamchk手动修复，不依赖日志重放
误配 Redo Log 参数对 MyISAM 的实际影响
即使你把 innodb_flush_log_at_trx_commit 设为 0，或把 innodb_log_file_size 调得极大，只要表是 ENGINE=MyISAM，这些设置就完全不生效：
- MySQL Server 层解析到 MyISAM 表时，会跳过所有 InnoDB 日志逻辑
-
SHOW ENGINE INNODB STATUS中的 Log 相关指标（如Log sequence number）只反映 InnoDB 实例状态，与 MyISAM 无关 - 如果混合使用 MyISAM 和 InnoDB 表，Redo Log 压力仅来自 InnoDB 的写入，MyISAM 的大量 INSERT 不会推高
Last checkpoint at差值
真正该关心 MyISAM 的日志类机制
MyISAM 有自己轻量级的日志辅助手段，但和 Redo Log 完全不是一回事：
-
myisam_recover_options：控制启动时是否自动检查并尝试修复表（如BACKUP,FORCE），本质是触发myisamchk流程 -
log_bin（binlog）：MyISAM 支持写 binlog，用于主从复制，但它记录的是 SQL 语句（STATEMENT）或行变更（ROW），不是物理页修改，也无法用于崩溃恢复 - 没有 undo log、没有 double write buffer、没有 checkpoint —— 它的设计哲学就是简单、快、无事务保障
混淆 Redo Log 和 MyISAM，往往是因为看到 /var/lib/mysql/ 下存在 ib_logfile* 就默认“MySQL 都有”，其实那些文件只是 InnoDB 引擎的私有资产，MyISAM 表哪怕占库容量 90%，也不会往里面写一个字节。
