インポート前後のInnoDBインデックス

私は過去の仕事でこの概念を少し実験しました。そこでは、MySQLサーバー間でスキーマをコピーする高速な方法が必要でした。

セカンダリインデックスを持つテーブルに挿入すると、実際にパフォーマンスのオーバーヘッドが発生します。インサートは、クラスター化インデックス（別名テーブル）を更新し、セカンダリインデックスも更新する必要があります。テーブルのインデックスが多いほど、挿入のオーバーヘッドが大きくなります。

InnoDBには、バッファーの変更> これはインデックスの更新を延期することで少し役立ちますが、最終的にはマージする必要があります。

MySQLのブランチであるPerconaServerは、mysqldump --optimize-keysを試してみました オプション。このオプションを使用すると、mysqldumpの出力がインデックスのないCREATE TABLEに変更され、次にすべてのデータがINSERTされ、次にALTERTABLEがデータのロード後にインデックスが追加されます。 https://www.percona.com/doc/を参照してくださいpercona-server / LATEST / management / innodb_expanded_fast_index_creation.html

しかし、私の経験では、パフォーマンスの正味の改善はわずかでした。インデックスのないテーブルであっても、多くの行を挿入するにはまだ時間がかかります。次に、リストアでALTERTABLEを実行してインデックスを作成する必要があります。大きなテーブルの場合、これにはしばらく時間がかかります。 INSERTの時間とインデックスを作成するための余分な時間を数えると、インデックスのあるテーブルに従来の方法で挿入するよりもわずか数パーセント（1桁下）速くなります。

この後処理インデックス作成のもう1つの利点は、インデックスがよりコンパクトに格納されることです。したがって、ディスクスペースを節約する必要がある場合は、この手法を使用するより良い理由です。

複数のテーブルを並行してロードすることで復元する方が、パフォーマンスにとってはるかに有益であることがわかりました。 。

• 新しいMySQL8.0ツール mysqlpump マルチスレッドダンプをサポートします。
• オープンソースツール mydumper マルチスレッドダンプをサポートし、myloaderと呼ばれるマルチスレッド復元ツールもあります 。 mydumper / myloaderの最悪の欠点は、ドキュメントが事実上存在しないことです。そのため、ドキュメントの実行方法を理解するには、勇敢なパワーユーザーである必要があります。

もう1つの戦略は、mysqldump --tabを使用することです。 SQLスクリプトの代わりにCSVファイルをダンプします。 CSVファイルの一括読み込みは、SQLスクリプトを実行してデータを復元するよりもはるかに高速です。それは、テーブル定義用のSQLファイルと、インポートするデータ用のCSVをダンプします。テーブルごとに個別のファイルを作成します。すべてのSQLファイルをロードしてテーブルを手動で再作成する必要があり（これは簡単です）、次に mysqlimport CSVデータファイルをロードします。 mysqlimportツールには--use-threadsもあります 並列実行のオプション。

異なる数の並列スレッドで慎重にテストします。私の経験では、4スレッドが最適です。並列処理が増えると、InnoDBがボトルネックになります。ただし、MySQLのバージョンとサーバーハードウェアのパフォーマンス容量によっては、エクスペリエンスが異なる場合があります。

すべての中で最速の復元方法は、物理バックアップツールを使用する場合です。最も一般的なのは、 Percona XtraBackup 。これにより、高速バックアップとさらに高速な復元が可能になります。バックアップされたファイルは、文字通り所定の場所にコピーして、ライブテーブルスペースファイルとして使用する準備ができています。欠点は、復元を実行するためにMySQLサーバーをシャットダウンする必要があることです。