実稼働環境にMySQL1.5GB MyISAMテーブル（1.0 GBデータ、0.5 GBインデックス）があり、これをInnoDBに変換しようとしています。
テーブルは本番環境で使用されるため、ダウンタイムをできるだけ短くしたいと思います。
私の質問：
スピードアップするには、どのMySQL構成オプションを調整する必要がありますALTER TABLE table_name ENGINE=InnoDB;か？
MyISAMからInnoDBへの本番データベーステーブルの変換を高速化するために、他にどのようなトリックを使用できますか？
innodb_buffer_pool_sizeをできるだけ高く設定することは、innodbテーブルの作成を高速化する一般的な方法です。データセットは2GBのinnodbバッファープール内に収まるように見えるため、適切な64ビットサーバーであればそれを許可する必要があります。alter table type = innodbは、dump + reimportソリューションよりも高速であり、並行して実行するのも簡単です。
また、innodb_log_file_sizeをデフォルトの5Mbから128または256MBに増やしたことを確認してください。これには注意してください。クリーンなシャットダウンと古いib_logfile*の消去が必要です。
サーバーに8GBのRAMがあり、64ビットバージョンのmysqlを実行している場合は、2GBのinnodb_buffer_poolをお勧めします。また、ダウンタイムのために閉じる前に、古いMYDファイルとMYIファイルを事前に読み取ることもできます。実際の作業開始時のOSのページキャッシュ。
マイナーな調整も行う場合は、データを安全に保つために、変換後に元に戻す必要があることを覚えておいてください（別の小さなダウンタイム）。ただし、このような小さなデータセットには価値があるとは思えません。
幸運を。
高速な（多少ローファイではありますが）ソリューションが必要な場合は、データをテキストファイルにエクスポートし（mysqldumpを介して）、結果のテキストファイルでテーブルタイプをInnoDBに変更してから、データを再インポートします。
ただし、問題がないことを確認するには、別のデータベースにインポートしてこれをテストする必要があります。
テーブルは書き込みのためにのみアクセスできなくなります。読み取りは、ALTERの期間中、古いMyISAMテーブルにアクセスし続けます。
真剣に、1.5Gテーブルの再構築は長くはかからないはずです。アプリがその量のダウンタイムに耐えられない場合は、これを行うために使用できるHAシステムをすでに用意しておく必要があります。おそらく、テクニカルサポートチームがダウンタイムについてユーザーに通知し、十分な警告を出すことができます。これは、平日の静かな時間に行います（通常、日曜日の朝が良い時間ですが、それは次の場合は異なる場合があります。イスラム諸国にはたくさんの顧客がいます）
同じ構成と仕様の非本番システムで同じサイズのデータをテーブルに実行することで、パフォーマンステストにかかる時間を確認できます。
pt-online-schema-changeを使用すると、問題は無関係になります。pt-online-schema-changeは、この問題を解決するためにPercona（おそらく世界でトップのMySQLコンサルタント会社）によって設計されたコマンドラインツールです。これにより、読み取りまたは書き込みをブロックすることなく、任意のテーブルでALTERステートメントを実行できます。これは、本番環境でこの変換を高速化しようとしている場合の実際の目標である可能性があります。
Percona Toolkitをインストールした後、O/Sシェルで次のコマンドを実行するだけです。
$ pt-online-schema-change h=your_host.com,t=your_db.your_target_table --alter "ENGINE=InnoDB"