myisam_recover_options 是只读系统变量，用于启动时检查并修复 myisam 表，因逻辑嵌入引擎初始化路径，修改后必须重启 mysqld 才生效。
MySQL 不支持运行中启用 MyISAM 自动修复，必须通过 myisam_recover_options 配置项在启动时触发，且仅对 MyISAM 表有效；InnoDB 完全不适用该机制。
myisam_recover_options 是什么，为什么只能重启生效
这是一个只读系统变量，控制 MySQL 启动时是否检查并尝试修复 MyISAM 表。它不是守护进程，也不监听运行时损坏事件——只有 mysqld 进程启动、首次打开某张 MyISAM 表时，才会按配置策略检查 .MYI 文件头是否标记为 crashed，或 open count 异常（如上次未正常关闭）。
因为它的逻辑嵌入在存储引擎初始化路径中，修改后必须重启 mysqld 才能加载新值。执行 SET GLOBAL myisam_recover_options = 'FORCE' 会报错 Variable 'myisam_recover_options' is a read only variable。
如何正确设置 myisam_recover_options 值
在 my.cnf 的 [mysqld] 段落下添加一行，例如：
[mysqld] myisam_recover_options = BACKUP,FORCE
可选值包括：OFF（默认禁用）、DEFAULT（等价于 BACKUP,FORCE）、BACKUP、FORCE、QUICK，多个值用英文逗号分隔。注意：QUICK 不会检查数据文件，只修索引；FORCE 会跳过校验强行重建，可能丢数据；BACKUP 会在修复前把原 .MYD 备份成 tablename-datetime.BAK。
设置后务必验证：
mysql> SHOW VARIABLES LIKE 'myisam_recover_options'; +------------------------+--------------+ | Variable_name | Value | +------------------------+--------------+ | myisam_recover_options | BACKUP,FORCE | +------------------------+--------------+
自动修复失败后，Comment 字段显示 crash recovery failed 怎么办
这说明启动时检测到表损坏，但内置修复流程已穷尽所有策略（快速修 → 重建数据 → 逐行恢复）仍失败。此时 myisam_recover_options 已无作用，必须人工介入：
- 确认表引擎确实是 MyISAM：
SHOW CREATE TABLE table_name中含ENGINE=MyISAM - 立即停库，用
myisamchk --safe-recover --force /var/lib/mysql/dbname/table_name.MYI尝试底层恢复 - 若仍失败，从最近一次
mysqldump或物理备份恢复，不要反复重试REPAIR TABLE
特别注意：myisam_recover_options 在 MySQL 8.0 中已被彻底移除，5.7 虽支持但官方标记为 deprecated；依赖它做“自动兜底”本身已是技术债。
误设 innodb_force_recovery 会导致 REPAIR TABLE 报错吗
不会直接导致报错，但会制造严重干扰：一旦设置了 innodb_force_recovery = 1–6，MySQL 会进入只读模式，所有写操作（包括 REPAIR TABLE）都会被拒绝，并报错 Can't execute the given command because you have active locked tables or an active transaction 或类似提示。而 REPAIR TABLE 本身对 InnoDB 表就无效，执行会返回 The storage engine for the table doesn't support repair。
更隐蔽的风险是：有人看到 MyISAM 表损坏，顺手开了 innodb_force_recovery 试图“加强恢复”，结果反而锁死整个实例的写能力，连导出都做不到。记住：两个参数完全无关，切勿混用。
