PHPMyAdmin 无法编辑 Mysql 解决方法

本想通过镜像重新把老站点搭建起来拷贝点文章内容，登录后台时发现忘记了密码，想着通过 PHPMyAdmin 修改 Mysql 数据库内容是非常简答的，万万没想到如下图提示错误：#1030 Get error -1 from storage engine，当时就想到可能因 InnoDB 引擎问题导致，查看在 Mysql 的 my.cnf 配置文件发现 innodb_force_recovery = 4，这就说明了自己的判断是正确的。

解决方法

接着就通过以下命令来修改 my.cnf 配置文件，将配置文件内的 innodb_force_recovery = 4 修改为 innodb_force_recovery = 0，修改完成执行 重载数据库 或 重启服务器，最后会讲到数字之间的区别，命令如下：

cd /etc/

vi my.cnf
innodb_force_recovery = X

# 修改
innodb_force_recovery = 0

# 重启
shutdown -r now

区别说明

当然作为 Mysql 的安全措施行为，InnoDB 在 innodb_force_recovery 大于 0 时，阻止 INSERT，UPDATE 或 DELETE 操作，对于 MySQL5.6 版本将 innodb_force_recovery 设为 4 或 更高 会让 InnoDB 处于只读模式。

1、SRV_FORCE_IGNORE_CORRUPT

即使服务器检测到损坏的页仍让它运行，试图使 SELECT* FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表

2、SRV_FORCE_NO_BACKGROUND

阻止主线程和任何清除线程的运行，如果崩溃会在清除操作中发生，该恢复值会阻止它

3 、SRV_FORCE_NO_TRX_UNDO

不要在崩溃恢复后运行事务回滚

4、SRV_FORCE_NO_IBUF_MERGE

阻止插入缓冲合并操作，如果它们会导致崩溃，不计算表统计，此值永久损坏数据文件，使用这个值后，准备号删除并重建所有辅助索引，在 MySQL5.6 中 InnoDB 为只读。

5、SRV_FORCE_NO_UNDO_LOG_SCAN

在启动数据库时不查看撤消日志：InnoDB将即使未完成的事务也作为已提交，这个值可以永久损坏数据文件，在 MySQL5.6 中 InnoDB 为只读。

6、SRV_FORCE_NO_LOG_REDO

不要通过恢复对重做日志进行前滚，这个值可能永久损坏数据文件，数据库页被留在一个陈旧的状态，这反过来又可能带给B-trees和其它数据库结构更多的损坏，在 MySQL5.6 中 InnoDB 为只读。