ibdata1内のUNDOテーブルスペースを介してロールバックが実行されているため、実際にできることはありません。
mysqldプロセスを終了してmysqlを再起動すると、クラッシュリカバリサイクルの一部として中断したところから再開されます。
免責事項：データ損失の責任はありません
他のテーブルのデータが失われる可能性がありますが、InnoDBの通常のクラッシュリカバリサイクルを回避するためにできることがいくつかあります。
innodb_force_recoveryと呼ばれる起動オプションがあり、InnoDBクラッシュリカバリのさまざまな段階をバイパスできます。
MySQLドキュメントの強制によるInnoDBリカバリによると、設定とその効果は次のとおりです。
1（SRV_FORCE_IGNORE_CORRUPT）
破損したページを検出した場合でも、サーバーを実行させます。SELECT * FROM tbl_nameが破損したインデックスレコードとページを飛び越えられるようにしてください。これはテーブルのダンプに役立ちます。
2（SRV_FORCE_NO_BACKGROUND）
マスタースレッドが実行されないようにします。パージ操作中にクラッシュが発生した場合、このリカバリ値によりクラッシュが防止されます。
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）
リカバリに関連してREDOログのロールフォワードを実行しないでください。
トランザクションの変更がUNDOおよびREDOログに埋め込まれていると、
- 書き込まれるはずのデータを失う
- 削除予定のデータを保持する
悪い副作用が予想される場合は、/ var / lib / mysql全体をバックアップし、ibdata1、ib_logfile0、およびib_logfile1をコピーして通常のリカバリを再試行する場合に備えて、どこかに置きます。
mysqlがいずれかのモードで完全に起動している場合
- mysqldumpは問題のテーブルを除くすべてのデータ
- mysqlのシャットダウン
- / var / lib / mysql / mysqlを除く/ var / lib / mysql内のすべてを削除します
- mysqlを起動する
- mysqldumpをリロードします
警告：必ずすべてをバックアップしてください!!!
これが役に立てば幸いです!!!