MySQLストレージエンジンの最適化：高性能のためのInnoDB最適化の構成

ハードウェアでのInnoDBのパフォーマンスを調整するには、次の手順に従います。

• innodb_data_file_pathを自動的に拡張するには、設定でautoextend属性を指定し、サーバーを再起動します。例：

  innodb_data_file_path =ibdata1：10M：autoextend  

autoextendパラメーターを使用すると、スペースが必要になるたびに、データファイルのサイズが8MBずつ自動的に増加します。新しい自動拡張データファイルも次のように指定できます（この場合、新しいデータファイルはibdata2と呼ばれます）：

  innodb_data_file_path =ibdata1：10M; ibdata2：10M：autoextend  

• InnoDBを使用する場合、使用される主なメカニズムはバッファープールです。 InnoDBはバッファープールに大きく依存しており、経験則として、innodb_buffer_pool_sizeパラメーターはサーバーで使用可能なRAMの合計の約60％から80％である必要があります。 OSで実行されているプロセス用にもRAMをいくらか残しておく必要があることに注意してください。

• InnoDBのinnodb_log_file_sizeはできるだけ大きく設定する必要がありますが、必要以上に大きくしないでください。この場合、パフォーマンスにはログファイルのサイズが大きいほど良いことに注意してください。ただし、ログファイルのサイズが大きいほど、クラッシュ後の回復時間が長くなります。そのため、「1つのサイズですべてに対応」するソリューションはありませんが、ログファイルの合計サイズは十分に大きい必要があると言われています。これは、MySQLサーバーがチェックポイントとディスクフラッシュアクティビティで定期的に作業するのを助けます。これにより、CPUとディスクのIOが大幅に節約され、ピーク時や高いワークロードアクティビティ時にスムーズに実行できます。推奨されるアプローチは、自分でテストして実験し、自分で最適な値を見つけることです。

• innodb_log_buffer_sizeの値は少なくとも16Mに設定する必要があります。大きなログバッファを使用すると、トランザクションがコミットしてディスクI / Oを節約する前に、ログをディスクに書き込むことなく、大きなトランザクションを実行できます。

• innodb_flush_log_at_trx_commitを調整する場合、このパラメーターは0、1、2の3つの値を受け入れることに注意してください。値が1の場合、ACIDに準拠します。値が0または2の場合、パフォーマンスは向上しますが、信頼性は低下します。その場合、ログがまだディスクにフラッシュされていないトランザクションがクラッシュで失われる可能性があるためです。

• innodb_lock_wait_timeoutを適切な値に設定するために、このパラメーターは前の時間を秒単位（デフォルト値は50）で定義することに注意してください。次のエラーを発行し、現在のステートメントをロールバックします：

 エラー1205（HY000）：ロック待機タイムアウトを超えました。トランザクションを再開してみてください 

• InnoDBでは、複数のフラッシュメソッドを使用できます。デフォルトでは、値がNULLに設定されている場合、この設定はWindowsマシンでは「async_unbuffered」に設定され、Linuxマシンでは「fsync」に設定されます。メソッドとその機能は次のとおりです。

• innodb_file_per_table設定を有効にすることも検討する必要があります。このパラメータは、MySQL5.6以降ではデフォルトでオンになっています。このパラメーターは、InnoDBテーブルを個別のファイルに格納し、肥大化したメインディクショナリとシステムテーブルを回避することで、InnoDBテーブルに関連する管理上の問題を軽減します。この変数を有効にすると、特定のテーブルが破損したときにデータ回復の複雑さに直面することも回避できます
• 上記の手順に従ってこれらの設定を変更したので、準備はほぼ整っているはずです。ただし、実行に移す前に、InnoDBインフラストラクチャ全体で最もビジーなファイルであるibdata1に注意を払う必要があります。

ibdata1の処理

ibdata1に保存される情報にはいくつかのクラスがあります：

1. InnoDBテーブルのデータ;
2. InnoDBテーブルのインデックス;
3. InnoDBテーブルのメタデータ;
4. 多バージョン同時実行制御（MVCC）データ;
5. 二重書き込みバッファー-このようなバッファーにより、InnoDBは半分書き込まれたページから回復できます。このようなバッファの目的は、データの破損を防ぐことです。
6. 挿入バッファー-このようなバッファーは、InnoDBが同じページへの更新をバッファーするために使用するため、更新を次々に実行するのではなく、一度に実行できます。

ビッグデータセットを処理する場合、ibdata1ファイルは非常に大きくなる可能性があり、これは非常に苛立たしい問題の核となる可能性があります。ファイルは拡大することしかできず、デフォルトでは縮小することはできません。 MySQLをシャットダウンしてこのファイルを削除することはできますが、何をしているのかを理解していない限り、これはお勧めしません。削除すると、ディクショナリとシステムテーブルがなくなるため、MySQLは正しく機能しなくなり、メインシステムテーブルが破損します。

ibdata1を完全に縮小するには、次の手順に従います。

1. InnoDBデータベースからすべてのデータをダンプします。このアクションには、mysqldumpまたはmysqlpumpを使用できます。
2. mysql、performance_schema、information_schemaデータベースを除くすべてのデータベースを削除します。
3. MySQLを停止します;
4. my.cnfファイルに次を追加します。コード>
5. ibdata1ファイルとib_logfile*ファイルを削除します（これらはMySQLの次回の再起動時に再作成されます）。
6. MySQLを起動し、前に取得したダンプからデータを復元します。上記の手順を実行した後も、ibdata1ファイルは大きくなりますが、InnoDBテーブルのデータは含まれなくなります。ファイルにはメタデータのみが含まれ、各InnoDBテーブルはibdata1の外部に存在します。ここで、/ var / lib / mysqlディレクトリに移動すると、InnoDBエンジンで使用している各テーブルを表す2つのファイルが表示されます。ファイルは次のようになります。
   1. demotable.frm
   2. demotable.ibd

.frmファイルにはストレージエンジンヘッダーが含まれ、.ibdファイルにはテーブルデータとテーブルのインデックスが含まれます。

ただし、変更をロールアウトする前に、インフラストラクチャに応じてパラメータを微調整してください。これらのパラメーターは、InnoDBのパフォーマンスを左右する可能性があるため、常にそれらを監視するようにしてください。これで、準備が整いました！