mysql Innodb在发生意外宕机，重启之后，要经历哪些过程，以下是详细过程。

• Tablespace discovery

Tablespace discovery is the process that InnoDB uses to identify tablespaces that require redo log application. See Tablespace Discovery During Crash Recovery.

• Redo log application

Redo log application is performed during initialization, before accepting any connections. If all changes are flushed from the buffer pool to the tablespaces (ibdata* and *.ibd files) at the time of the shutdown or crash, redo log application is skipped. InnoDB also skips redo log application if redo log files are missing at startup.

Removing redo logs to speed up recovery is not recommended, even if some data loss is acceptable.Removing redo logs should only be considered after a clean shutdown, with innodb_fast_shutdown set to 0 or 1.

For information about the process that InnoDB uses to identify tablespaces that require redo log application, see Tablespace Discovery During Crash Recovery.

• Roll back of incomplete transactions

Incomplete transactions are any transactions that were active at the time of crash or fast shutdown.

The time it takes to roll back an incomplete transaction can be three or four times the amount of time a

transaction is active before it is interrupted, depending on server load.

You cannot cancel transactions that are being rolled back. In extreme cases, when rolling back

transactions is expected to take an exceptionally long time, it may be faster to start InnoDB with an

innodb_force_recovery setting of 3 or greater. See Section 15.21.2, “Forcing InnoDB Recovery”.

• Change buffer merge

Applying changes from the change buffer (part of the system tablespace) to leaf pages of secondary

indexes, as the index pages are read to the buffer pool.

• Purge

Deleting delete-marked records that are no longer visible to active transactions.

The steps that follow redo log application do not depend on the redo log (other than for logging the writes)

and are performed in parallel with normal processing. Of these, only rollback of incomplete transactions is

special to crash recovery. The insert buffer merge and the purge are performed during normal processing.

After redo log application, InnoDB attempts to accept connections as early as possible, to reduce

downtime. As part of crash recovery, InnoDB rolls back transactions that were not committed or in XA

PREPARE state when the server crashed. The rollback is performed by a background thread, executed in

parallel with transactions from new connections. Until the rollback operation is completed, new connections

may encounter locking conflicts with recovered transactions.

In most situations, even if the MySQL server was killed unexpectedly in the middle of heavy activity,

the recovery process happens automatically and no action is required of the DBA. If a hardware

failure or severe system error corrupted InnoDB data, MySQL might refuse to start. In this case, see

更多请翻阅MySQL官网相关章节 Section 15.21.2, “Forcing InnoDB Recovery”.