网站突然报错--数据库链接失败！
下意识的登上服务器，以为重启一下mysqld服务就能轻松解决，但想象总是美好的。
当我点击启动之后，提示已启动，高高兴兴返回站点首页刷新，突然还报错一样的信息。这时才意识到可能问题并没有那么简单。
再回到服务器中查看，依次点击“重启”/“修复启动”，结果都是一样的。显示成功，但结果都是失败。
只能翻翻日志分析错误原因了。
密密麻麻一堆，还好找出了问题的关键。
根据日志信息分析基本上定位数据库损坏，然后日志给一个参考链接 forcing-innodb-recovery 。翻阅文档映入眼帘的就只有一行重点
[mysqld]
innodb_force_recovery = 1于是打开配置配置项，填入参数。重启/mysqld服务启动正常。立马对数据库已存在的数据进行备份。正常以后，再去除了以上配置。
事后又对故障原因进行了整理分析：
innodb_force_recovery是一个强制恢复模式参数，当MySQL InnoDB存储引擎因各种原因崩溃或无法正常启动时，通过设置此参数可以绕过某些检查，允许数据库以只读模式启动，从而进行数据恢复操作。
而且innodb_force_recovery还有不同的取值对应不同损害程度的处理。
| 级别 | 作用 | 适用场景 |
|---|---|---|
| 0 (默认) | 正常模式，不跳过任何检查 | 健康运行状态 |
| 1 | 跳过重做日志（redo log）检查 | 重做日志损坏 |
| 2 | 跳过撤销日志（undo log）检查 | 撤销日志损坏 |
| 3 | 跳过插入缓冲（insert buffer）检查 | 插入缓冲损坏 |
| 4 | 跳过非唯一二级索引检查 | 二级索引损坏 |
| 5 | 跳过唯一二级索引检查 | 唯一索引损坏 |
| 6 | 跳过系统表检查 | 系统表损坏 |
MySQL启动流程
↓
检查 innodb_force_recovery 值
↓
根据级别跳过相应检查
↓
以只读模式启动InnoDB
↓
允许执行SELECT和SHOW命令
↓
进行数据导出和备份innodb_force_recovery = 1 是一个救命稻草式的参数，用于在数据库严重损坏时进行数据抢救。虽然存在风险，但在正确使用的情况下，可以避免数据丢失。