查看了mysql的日志
分析日志后发现，数据库无法重启的原因是因为ibdata1文件损坏，重启后无法正常恢复。
解决办法：
需要跳过恢复步骤，修改my.cnf文件，在my.cnf中的[mysqld]中添加：
innodb_force_recovery = 6
innodb_purge_threads = 1
解释：
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
具体数字对应的含义：
1-----(SRVFORCEIGNORECORRUPT):忽略检查到的corrupt页。
2-----(SRVFORCENOBACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
3-----(SRVFORCENOTRXUNDO):不执行事务回滚操作。
4-----(SRVFORCENOIBUFMERGE):不执行插入缓冲的合并操作。
5-----(SRVFORCENOUNDOLOGSCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6-----(SRVFORCENOLOG_REDO):不执行前滚的操作。
注意
MySQL数据库，当innodb表空间损坏时候，尝试启动数据库不成功，可以使用innodb_force_recovery参数进行强制启动
在主配置文件my.cnf中添加
innodb_force_recovery=6
****************************
innodb_force_recovery参数解释：
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况，默认值为0，表示当需要恢复时执行所有的恢复操作。
当不能进行有效的恢复操作时，mysql有可能无法启动，并记录下错误日志。
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash
3(SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
4(SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志，InnoDB存储引擎会将未提交的事务视为已提交。
6(SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。
***************************
修复表空间受损的表：
数据起来后，innodb类型的表不能写操作，但可以读，此时对表做check，查找到异常的表，读取出来，导入到myisam表里面，drop原表
然后在my.cnf中去掉innodb_force_recovery的设置，重启mysql
把myisam表转成innodb表；
再次启动mysql就ok了~
如果还无法启动，则需要删除数据目录datafile下的 ibdata1,ib_logfile*等文件。
启动后导出MySQL数据库，重新恢复即可。