问题描述
1 mysql数据库5.6无法正常启动
2 直接复制替换innodb的frm和idb文件来新增数据表导致的问题
3 innodb文件ibdata1，ib_logfile0，ib_logfile1损坏，数据不一致
4 没有sql备份，无法正常登陆和导出当天数据
注意事项
innodb的表不能直接复制替换frm和idb文件，而是使用工具正常导入导出，myisam表可以直接复制替换文件
解决方法
1 开启mysql错误日志，观察日志来判断数据库什么问题（此次问题比较清楚，innodb损坏，ibdata1损坏导致）
2 innodb_force_recovery （0-6级别） 此次使用6强制启动
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_force_recovery大于0后，可以对标进行select、create、drop操作，但insert、update或者delete这类操作是不允许的
3 innodb_force_recovery=6 正常启动mysql后，无法使用navicat工具导出数据量大的的数据库，正常工具导出还会导致数据库崩溃（此处没有最近的sql备份，只有损坏后数据库目录直接备份，但是ibdata1损坏，所以这个备份没有意义，所以此处还是要导出正常的sql备份，用来恢复当天最近的数据）
4 尝试使用innochecksum -f ibdata1工具来修复ibdata损坏,但是没有效果
5 使用mysqldump命令进行导出（此处遇到问题，和原来业务的数据编码问题，重新创建mysql环境，数据库创建问题，表创建问题，索引创建问题）
1 数据编码问题，此处并不是普通的中文乱码问题，而是编码: JUSTEP154053; 提示: KSQL语法错误，源程序服务tomcat启动问题
这个编码问题分为两步 ：tomcat启动报错，数据库和表的编码问题，tomcat正常启动后里的程序页面报错，这是数据的编码问题
2 此处遇到数据库，表创建，数据问题，手动创建新的utf-8，但是不生效，虽然都和原环境一直，但还是会出现编码报错，业务有问题
3 解决无论导入和导出都需要加上--default-character-set=utf8（防止编码: JUSTEP154053，防止mysql错误导入ERROR 1064 (42000)）
4 此次为了快速解决，使用了原来2018-04月的备份数据库，使用原来数据库的库和表结构，清空数据
5 导出来加-t 只导出数据，不导出表结构
6 解决步骤
1 导出三个库所需的数据 --default-character-set=utf8 只导出数据，不导结构
2 确保导出备份数据可以使用后，删除原有数据库文件
3 备份MySQL数据目录下的ib_logfile0、ib_logfile1、ibdata1三个文件，然后将这三个文件删除
4 innodb_force_recovery = 0 重新启动mysql 重建 ib_logfile0、ib_logfile1、ibdata1 此时所有数据表都无法打开
5 重新导入数据文件 --default-character-set=utf8 导入数据
mysql数据恢复通过frm和idb文件（此处没有使用）
记录参考https://blog.csdn.net/Sonny_alice/article/details/80198200
整个恢复过程其实可以总结为下面几步：
一：无表数据结构
(1)：恢复表结构
(2)：复制出来创建表的sql语句
(3)：恢复表数据(在恢复表数据的时候，首先需要解除当前创建的表与默认生成的.ibd文件间的关系，接着将要恢复数据表的.ibd文件与当前创建的表联系起来即可)
(4)：alter table songlyric discard tablespace;alter table songlyric import tablespace;