InnoDB Forcing Recovery official document: HTTPS: // dev.mysql.com / DOC / RefMan / 5.7 / EN / Forcing - InnoDB - recovery.html To survey database page corruption, you can use SELECT table from a database dump. . . Enter the outer island. Generally, most of the data obtained by this method is complete. Severe damage may cause the SELECT * FROM tbl_name statement or InnoDB background operation to crash or assert, or even cause InnoDB roll-forward recovery to crash. In this case, you can use the innodb_force_recovery option to force the innodb storage engine to start while dumping background operations while dumping tables. For example, before restarting the server, you can add the following line to the [ mysqld ] section of the options file : [ mysqld ] innodb_force_recovery = 1 warning: Only set innodb_force_recovery to a value greater than 0 in an emergency, so that you can start innodb and dump the table. Before doing this, make sure you have a backup copy of the database in case you need to recreate it. A value of 4 or greater may permanently damage the data file. Only after successfully testing the innodb_force_recovery setting on a separate physical copy of the database can you use this setting 4 or higher on the production server instance. When you enforce InnoDB recovery, you should always start with InnoDB_force_recovery = 1, and only increment this value when necessary. innodb_force_recovery defaults to 0 (normal startup, no forced recovery). The allowed non-zero values of innodb_force_recovery are 1 to 6. Larger values include functions with smaller values. For example, value 3 includes all functions of values 1 and 2. If you can dump the table with innodb force_recovery value less than or equal to 3, then you are relatively safe, and only some data on the damaged single page will be lost. A value of 4 or greater is considered dangerous because the data file may be permanently damaged. The value 6 is considered extreme because the database pages are outdated, which in turn may cause damage to B-trees and other database structures. As a security measure, when InnoDB force_recovery is greater than 0, InnoDB prevents insert, update, or delete operations. innodb_force_recovery is set to 4 or more locations innodb in read-only mode. 1 (SRV_FORCE_IGNORE_CORRUPT) allows the server to run even if it detects damaged pages. Try to make SELECT * FROM tbl_name skip the damaged index records and pages, which helps dump the table. 2(SRV_FORCE_NO_background) Prevent the main thread and any clearing threads from running. If a crash occurs during the purge operation, this recovery value will prevent the crash. 3 (SRV_FORCE_NO_TRX_UNDO) Do not run transaction rollback after crash recovery. 4 (SRV_FORCE_NO_IBUF_MERGE) prevents insert buffer merge operations. If they cause a crash, don't do it. Does not calculate table statistics. This value may permanently damage the data file. After using this value, be prepared to delete and re-create all secondary indexes. Set InnoDB to read-only. 5 (SRV_FORCE_NO_UNDO_LOG_scan) Do not view the undo log when starting the database: InnoDB even treats incomplete transactions as committed. This value may permanently damage the data file. Set InnoDB to read-only. 6 (SRV_FORCE_NO_LOG_Redo) Do not perform redo log roll forward related to recovery. This value may permanently damage the data file. Leave database pages out of date, which in turn may lead to damage to B-trees and other database structures. Set InnoDB to read-only. You can choose from the table to dump them. If the innodb_force_recovery value is less than or equal to 3, you can delete or create the table. The DROP TABLE supports innodb_force_recovery greater than 3, until the MySQL 5.7 . . 17 . From MySQL 5.7Starting from .18, when the value of innodb_force_recovery is greater than 4, DROP TABLE is not allowed . If you know that a given table causes a crash when it is rolled back, you can delete it. If you encounter uncontrolled rollback due to bulk import or ALTER TABLE failure, you can terminate the mysqld process and set innodb_force_recovery to 3 to start the database without rolling back, and then delete the table that caused the uncontrolled rollback. If corruption in the table data prevents you from dumping the entire table content, queries using the ORDER BY primary_key DESC clause may be able to dump parts of the table after the damaged part. If starting innodb requires a higher value of innodb force_recovery, there may be a corrupted data structure, resulting in the failure of complex queries (queries containing WHERE, ORDER BY, or other clauses). In this case, you may only be able to run basic SELECT * FROM t queries.