我的MySQL服务器5.7崩溃，甚至没有启动后，添加innodb_force_recovery。 我试了innodb_force_recovery = 1到6的所有值，但没有任何工作。
请帮助现在做什么，以及如何手动或通过使用其他库恢复/修复损坏的InnoDB表？
我没有备份，只剩下损坏大小为10GB的InnoDB表文件。
syslog在每次尝试后显示以下行：
May 21 10:02:33 server2 kernel: [ 3137.604417] audit: type=1400 audit(1495341153.370:19): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/mysqld" pid=24185 comm="apparmor_parser" May 21 10:02:33 server2 mysqld_safe: Logging to '/var/log/mysql/error.log'. May 21 10:02:33 server2 mysqld_safe: Logging to '/var/log/mysql/error.log'. May 21 10:02:33 server2 mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql May 21 10:02:33 server2 mysqld[24557]: /usr/sbin/mysqld (mysqld 5.7.17) starting as process 24557 ... May 21 10:02:33 server2 mysqld[24557]: InnoDB: PUNCH HOLE support available May 21 10:02:33 server2 mysqld[24557]: InnoDB: Mutexes and rw_locks use GCC atomic builtins May 21 10:02:33 server2 mysqld[24557]: InnoDB: Uses event mutexes May 21 10:02:33 server2 mysqld[24557]: InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier May 21 10:02:33 server2 mysqld[24557]: InnoDB: Compressed tables use zlib 1.2.3 May 21 10:02:33 server2 mysqld[24557]: InnoDB: Using Linux native AIO May 21 10:02:33 server2 mysqld[24557]: InnoDB: Number of pools: 1 May 21 10:02:33 server2 mysqld[24557]: InnoDB: Using CPU crc32 instructions May 21 10:02:33 server2 mysqld[24557]: InnoDB: Initializing buffer pool, total size = 1G, instances = 8, chunk size = 128M May 21 10:02:33 server2 mysqld[24557]: InnoDB: Completed initialization of buffer pool May 21 10:02:33 server2 mysqld[24557]: InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). May 21 10:02:33 server2 mysqld[24557]: InnoDB: Highest supported file format is Barracuda. May 21 10:02:33 server2 mysqld[24557]: InnoDB: Log scan progressed past the checkpoint lsn 1903477238014 May 21 10:02:33 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903482480640 May 21 10:02:34 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903478876160 May 21 10:02:34 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903484119040 May 21 10:02:34 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903486713411 May 21 10:02:34 server2 mysqld[24557]: InnoDB: Database was not shutdown normally! May 21 10:02:34 server2 mysqld[24557]: InnoDB: Starting crash recovery. May 21 10:02:34 server2 mysqld[24557]: InnoDB: Space id and page no stored in the page, read in are [page id: space=0, page number=224284], should be [page id: space=0, page number=360462] May 21 10:02:34 server2 mysqld[24557]: InnoDB: Database page corruption on disk or a failed file read of page [page id: space=0, page number=360462]. You may have to recover from a backup. May 21 10:02:34 server2 mysqld[24557]: InnoDB: Page dump in ascii and hex (16384 bytes): May 21 10:02:34 server2 mysqld[24557]: InnoDB: Uncompressed page, stored checksum in field1 1176070173, calculated checksums for field1: crc32 1474463089/3411817011, innodb 1277319011, none 3735928559, stored checksum in field2 2383263673, calculated checksums for field2: crc32 1474463089/3411817011, innodb 3335309735, none 3735928559, page LSN 443 804368015, low 4 bytes of LSN at page end 801385784, page number (if stored to page already) 224284, space id (if created with >= MySQL-4.1.1 and stored already) 0 May 21 10:02:34 server2 mysqld[24557]: InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery. May 21 10:02:34 server2 mysqld[24557]: [FATAL] InnoDB: Aborting because of a corrupt database page in the system tablespace. Or, there was a failure in tagging the tablespace as corrupt. May 21 10:02:34 server2 mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended 在MySQL的日志消息中给出如此多的build议以简单，可读的英文不是很棒的！
InnoDB：您的操作系统也有可能损坏了自己的文件caching，重新启动计算机会消除错误。 如果损坏的页面是索引页面。 你也可以尝试通过倾倒，丢弃和重新导入腐败表来修复腐败。 您可以使用
CHECK TABLE来扫描您的表格是否损坏。 有关强制恢复的信息，请参阅http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html 。
这是你已经尝试过的。 当你仍然无法启动时，通过转储数据库重新导入来运行任何SQL查询或命令来解决这个问题显然是不可能的。 如果您在innodb_force_recovery之前也重新启动，则会留下最后一个选项，也可以从日志中find：
InnoDB：磁盘上的数据库页面损坏或页面失败的文件读取
[page id: space=0, page number=360462]。 您可能需要从备份中恢复。
你有备份，对吧？
没有备份，最后的希望可能是用于InnoDB的Percona数据恢复工具 。
这个项目是一套从InnoDB的数据文件中恢复丢失或损坏的MySQL数据的工具。 它是在Percona创build的，为社区使用而开源。
我与Percona没有任何关系，只推荐开源工具和文档 。