true または false であるシステム変数は、サーバー起動時に変数の名前を指定することで有効にすることができ、--skip- プリフィクスを使用することで無効にすることができます。 たとえば、InnoDB 適応ハッシュインデックスを有効または無効にするには、コマンドラインで --innodb-adaptive-hash-index または --skip-innodb-adaptive-hash-index を使用するか、オプションファイルで innodb_adaptive_hash_index または skip_innodb_adaptive_hash_index を使用します。

数値が指定されるシステム変数は、コマンド行で --var_name=value として指定するか、オプションファイルで var_name=value として指定できます。

多くのシステム変数は、実行時に変更できます (セクション5.1.9.2「動的システム変数」を参照してください)。

GLOBAL および SESSION 変数スコープ修飾子については、SET ステートメントのドキュメントを参照してください。

特定のオプションでは、InnoDB データファイルの場所およびレイアウトが制御されます。セクション15.8.1「InnoDB の起動構成」では、これらのオプションを使用する方法について説明します。

初期段階では使用しないような一部のオプションは、マシンの処理能力やデータベースのワークロードに基づいて、InnoDB のパフォーマンス特性を調整する際に役立ちます。

オプションおよびシステム変数の指定に関する詳細は、セクション4.2.2「プログラムオプションの指定」を参照してください。

--innodb[=value]

サーバーが InnoDB サポートでコンパイルされた場合に、InnoDB ストレージエンジンのロードを制御します。 このオプションの形式はトライステートであり、指定可能な値は OFF、ON、または FORCE です。 セクション5.6.1「プラグインのインストールおよびアンインストール」を参照してください。

InnoDB を無効にするには、--innodb=OFF または --skip-innodb を使用します。 この場合、デフォルトのストレージエンジンは InnoDB であるため、--default-storage-engine および --default-tmp-storage-engine を使用して永続テーブルと TEMPORARY テーブルの両方のデフォルトをほかのエンジンに設定しないかぎり、サーバーは起動しません。

InnoDB ストレージエンジンを無効にすることはできなくなり、--innodb=OFF および --skip-innodb オプションは非推奨であり、効果はありません。 使用すると警告が表示されます。 これらのオプションは、将来の MySQL リリースで削除される予定です。

--innodb-status-file

--innodb-status-file の起動オプションは、InnoDB が innodb_status.pid という名前のファイルをデータディレクトリに作成し、SHOW ENGINE INNODB STATUS 出力を 15 秒ごとにおよそ書き込むかどうかを制御します。

innodb_status.pid ファイルはデフォルトでは作成されません。 これを作成するには、--innodb-status-file オプションを指定して mysqld を起動します。 サーバーが正常に停止すると、InnoDB によってファイルが削除されます。 異常停止が発生した場合は、ステータスファイルを手動で削除する必要がある場合があります。

--innodb-status-file オプションは一時的な使用を目的としています。これは、SHOW ENGINE INNODB STATUS の出力生成がパフォーマンスに影響し、innodb_status.pid ファイルが時間の経過とともに非常に大きくなる可能性があるためです。

関連情報については、セクション15.17.2「InnoDB モニターの有効化」を参照してください。

--skip-innodb

InnoDB ストレージエンジンを無効にします。 --innodb の説明を参照してください。

daemon_memcached_enable_binlog

MySQL binary log で InnoDB memcached プラグイン (daemon_memcached) を使用するには、ソースサーバーでこのオプションを有効にします。 このオプションは、サーバーの起動時にのみ設定できます。 --log-bin オプションを使用して、ソースサーバーで MySQL バイナリログを有効にする必要もあります。

詳細は、セクション15.20.7「InnoDB memcached プラグインとレプリケーション」を参照してください。

daemon_memcached_engine_lib_name

InnoDB memcached プラグインを実装する共有ライブラリを指定します。

詳細は、セクション15.20.3「InnoDB memcached プラグインの設定」を参照してください。

daemon_memcached_engine_lib_path

InnoDB memcached プラグインを実装する共有ライブラリを含むディレクトリのパスです。 デフォルト値は、MySQL プラグインディレクトリを表す NULL です。 MySQL プラグインディレクトリの外部にある別のストレージエンジン用の memcached プラグインを指定しないかぎり、このパラメータを変更する必要はありません。

詳細は、セクション15.20.3「InnoDB memcached プラグインの設定」を参照してください。

daemon_memcached_option

起動時に、空白文字で区切られた memcached オプションをベースとなる memcached メモリーオブジェクトのキャッシュデーモンに渡すために使用されます。 たとえば、memcached がリスニングするポートの変更、同時接続の最大数の削減、キーと値のペアの最大メモリーサイズの変更、またはエラーログのデバッグメッセージの有効化を行うことができます。

使用法の詳細は、セクション15.20.3「InnoDB memcached プラグインの設定」を参照してください。 memcached オプションについては、memcached のマニュアルページを参照してください。

daemon_memcached_r_batch_size

COMMIT を実行して新しいトランザクションを開始する前に実行する memcached 読取り操作 (get 操作) の数を指定します。 daemon_memcached_w_batch_size の対の片方です。

この値はデフォルトで 1 に設定されているため、SQL ステートメントを介してテーブルに加えられた変更は、memcached 操作からすぐに参照できます。 ベースとなるテーブルが memcached インタフェースからのみアクセスされているシステム上で、頻繁なコミットによるオーバーヘッドを削減するために、これを大きくすることがあります。 大きすぎる値を設定すると、Undo データまたは Redo データの量によっては、長時間実行されるトランザクションの場合と同様に、一部のストレージでオーバーヘッドが発生する可能性があります。

詳細は、セクション15.20.3「InnoDB memcached プラグインの設定」を参照してください。

daemon_memcached_w_batch_size

COMMIT を実行して新しいトランザクションを開始する前に実行する、add、set、incr などの memcached 書込み操作の数を指定します。 daemon_memcached_r_batch_size の対の一方です。

格納されるデータは停止時に保持することが重要であり、すぐにコミットする必要があると仮定すると、この値はデフォルトで 1 に設定されます。 クリティカルでないデータを格納する場合、頻繁なコミットによるオーバーヘッドを削減するためにこの値を増やすことができますが、予期しない終了が発生すると、最後の N-1 のコミットされていない書込み操作が失われる可能性があります。

詳細は、セクション15.20.3「InnoDB memcached プラグインの設定」を参照してください。

innodb_adaptive_flushing

ワークロードに基づいて、InnoDB バッファープール内のダーティーページをフラッシュする比率を動的に調整するかどうかを指定します。 フラッシュ比率を動的に調整する目的は、I/O アクティビティーのバーストを回避することです。 この設定はデフォルトで有効になっています。 詳しくはセクション15.8.3.5「バッファープールのフラッシュの構成」をご覧ください。 一般的な I/O チューニングのアドバイスについては、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

innodb_adaptive_flushing_lwm

adaptive flushing が有効な redo log 容量の割合を表す最低水位標を定義します。 詳細は、セクション15.8.3.5「バッファープールのフラッシュの構成」を参照してください。

innodb_adaptive_hash_index

InnoDB 適応型ハッシュインデックスが有効と無効のどちらになっているのかを示します。 ワークロードに応じて、適応型ハッシュインデックスの作成を動的に有効または無効にして、クエリーのパフォーマンスを改善することが望ましい場合があります。 適応型ハッシュインデックスがすべてのワークロードに役立つとは限らないため、現実的なワークロードを使用して、有効と無効の両方でベンチマークを実施してください。 詳細は、セクション15.5.3「適応型ハッシュインデックス」を参照してください。

この変数はデフォルトで有効になっています。 SET GLOBAL ステートメントを使用すると、サーバーを再起動せずに、このパラメータを変更できます。 実行時に設定を変更するには、グローバルシステム変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。 サーバーの起動時に --skip-innodb-adaptive-hash-index を使用して無効にすることもできます。

適応型ハッシュインデックスを無効にすると、すぐにハッシュテーブルが空になります。 ハッシュテーブルが空になっても通常の操作は続行でき、ハッシュテーブルを使用していた実行中のクエリーは、代わりにインデックスの B ツリーに直接アクセスします。 適応型ハッシュインデックスを再度有効にすると、通常の操作時にハッシュテーブルが再度移入されます。

innodb_adaptive_hash_index_parts

適応ハッシュインデックス検索システムをパーティション化します。 各インデックスは特定のパーティションにバインドされ、各パーティションは個別のラッチで保護されます。

適応ハッシュインデックス検索システムは、デフォルトで 8 つの部分にパーティション化されています。 最大設定は 512 です。

関連情報については、セクション15.5.3「適応型ハッシュインデックス」を参照してください。

innodb_adaptive_max_sleep_delay

InnoDB で、現在のワークロードに応じて innodb_thread_sleep_delay の値を自動的に調整できます。 ゼロ以外の値を指定すると、innodb_adaptive_max_sleep_delay オプションで指定した最大値まで、innodb_thread_sleep_delay 値の動的な自動調整が可能になります。 値はマイクロ秒数を表しています。 このオプションは、InnoDB スレッド数が 16 個を上回る高負荷のシステムで役立つことがあります。 (実際には、同時接続数が数百または数千になる MySQL システムの大部分の変数です。)

詳細は、セクション15.8.4「InnoDB のスレッド並列性の構成」を参照してください。

innodb_api_bk_commit_interval

InnoDB memcached インタフェースが使用されるアイドル状態の接続が自動コミットされる頻度 (秒単位) です。 詳細は、セクション15.20.6.4「InnoDB memcached プラグインのトランザクション動作の制御」を参照してください。

innodb_api_disable_rowlock

InnoDB memcached が DML 操作を実行するときに行ロックを無効にするには、このオプションを使用します。 デフォルトでは、innodb_api_disable_rowlock は無効になっています。これは、memcached が get および set 操作の行ロックを要求することを意味します。 innodb_api_disable_rowlock が有効な場合、memcached は行ロックではなくテーブルロックを要求します。

innodb_api_disable_rowlock は動的ではありません。 これは mysqld コマンド行で指定するか、または MySQL 構成ファイルに入力する必要があります。 構成は、MySQL サーバーの起動時に発生するプラグインのインストール時に有効になります。

詳細は、セクション15.20.6.4「InnoDB memcached プラグインのトランザクション動作の制御」を参照してください。

innodb_api_enable_binlog

MySQL バイナリログとともに、InnoDB memcached プラグインを使用できます。 詳細は、InnoDB memcached バイナリログの有効化を参照してください。

innodb_api_enable_mdl

InnoDB memcached プラグインで使用されるテーブルをロックします。これにより、SQL インタフェースから DDL によって削除または変更できなくなります。 詳細は、セクション15.20.6.4「InnoDB memcached プラグインのトランザクション動作の制御」を参照してください。

innodb_api_trx_level

memcached インタフェースによって処理されるクエリーのトランザクション isolation level を制御します。 よく聞く名前に対応する定数は、次のとおりです。

詳細は、セクション15.20.6.4「InnoDB memcached プラグインのトランザクション動作の制御」を参照してください。

innodb_autoextend_increment

自動拡張 InnoDB system tablespace ファイルがいっぱいになったときにサイズを拡張するための増分サイズ (MB)。 デフォルト値は 64 です。 関連情報については、システムテーブルスペースデータファイル構成,およびシステムテーブルスペースのサイズ変更を参照してください。

innodb_autoextend_increment 設定は、file-per-table テーブルスペースファイルまたは general tablespace ファイルには影響しません。 これらのファイルは、innodb_autoextend_increment の設定に関係なく自動拡張されます。 拡張は少量で始まり、その後の拡張は増分が 4MB で発生します。

innodb_autoinc_lock_mode

自動インクリメント値を生成する際に使用されるロックモードです。 許容値は、従来型、連続型またはインターリーブ型の場合、それぞれ 0、1 または 2 です。

デフォルト設定は、MySQL 8.0 の時点では 2 (インターリーブ)、それより前では 1 (連続) です。 デフォルト設定としてインターリーブロックモードを変更すると、MySQL 5.7 で発生したデフォルトのレプリケーションタイプとして、ステートメントベースから行ベースのレプリケーションへの変更が反映されます。 ステートメントベースレプリケーションでは、SQL ステートメントの特定のシーケンスに対して自動インクリメント値が予測可能かつ繰り返し可能な順序で割り当てられるように、連続した自動インクリメントロックモードが必要ですが、行ベースレプリケーションは SQL ステートメントの実行順序には影響しません。

各ロックモードの特性については、InnoDB AUTO_INCREMENT のロックモード を参照してください。

innodb_background_drop_list_empty

innodb_background_drop_list_empty デバッグオプションを有効にすると、バックグラウンドドロップリストが空になるまでテーブルの作成が遅延されるため、テストケースの失敗を回避できます。 たとえば、テストケース A がテーブル t1 をバックグラウンドドロップリストに配置する場合、テストケース B はバックグラウンドドロップリストが空になるまで待機してから、テーブル t1 を作成します。

innodb_buffer_pool_chunk_size

innodb_buffer_pool_chunk_size は、InnoDB バッファプールのサイズ変更操作のチャンクサイズを定義します。

サイズ変更操作中にすべてのバッファプールページがコピーされないようにするために、この操作は 「chunks」 で実行されます。 デフォルトでは、innodb_buffer_pool_chunk_size は 128MB (134217728 バイト) です。 チャンクに含まれるページ数は、innodb_page_size の値によって異なります。innodb_buffer_pool_chunk_size は、1MB (1048576 バイト) 単位で増減できます。

innodb_buffer_pool_chunk_size 値を変更する場合は、次の条件が適用されます:

潜在的なパフォーマンスの問題を回避するには、チャンク (innodb_buffer_pool_size / innodb_buffer_pool_chunk_size) の数が 1000 を超えないようにする必要があります。

innodb_buffer_pool_size 変数は動的で、サーバーがオンラインのときにバッファプールのサイズを変更できます。 ただし、バッファプールサイズは innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances の倍数である必要があり、これらの変数設定のいずれかを変更するにはサーバーを再起動する必要があります。

詳しくはセクション15.8.3.1「InnoDB バッファプールサイズの構成」をご覧ください。

innodb_buffer_pool_debug

このオプションを有効にすると、バッファプールのサイズが 1GB 未満の場合に複数のバッファプールインスタンスが許可され、innodb_buffer_pool_instances に設定されている 1GB の最小バッファプールサイズ制約は無視されます。 innodb_buffer_pool_debug オプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_buffer_pool_dump_at_shutdown

MySQL サーバーの停止時に InnoDB buffer pool にキャッシュされたページを記録して、次回の再起動時に warmup プロセスを短縮するかどうかを指定します。 一般に、innodb_buffer_pool_load_at_startup と組み合わせて使用されます。 innodb_buffer_pool_dump_pct オプションは、ダンプする最後に使用されたバッファープールページの割合を定義します。

innodb_buffer_pool_dump_at_shutdown と innodb_buffer_pool_load_at_startup の両方がデフォルトで有効になっています。

詳細は、セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

innodb_buffer_pool_dump_now

InnoDB buffer pool にキャッシュされたページをすぐに記録します。 一般に、innodb_buffer_pool_load_now と組み合わせて使用されます。

詳細は、セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

innodb_buffer_pool_dump_pct

各バッファープールが読み出してダンプする直近で使用されたページの割合を指定。 指定できる範囲は 1～ 100 です。 デフォルト値は 25 です。 たとえば、100 ページのバッファプールが 4 つあり、innodb_buffer_pool_dump_pct が 25 に設定されている場合、各バッファプールから最近使用された 25 ページがダンプされます。

innodb_buffer_pool_filename

innodb_buffer_pool_dump_at_shutdown または innodb_buffer_pool_dump_now で生成されるテーブルスペース ID およびページ ID のリストを保持するファイルの名前を指定します。 テーブルスペース ID およびページ ID は、space, page_id という形式で保存されます。 デフォルトでは、ファイルの名前は ib_buffer_pool で、InnoDB データディレクトリにあります。 データディレクトリに対してデフォルト以外の場所を指定する必要があります。

SET ステートメントを使用して、実行時にファイル名を指定できます:

SET GLOBAL innodb_buffer_pool_filename='file_name';

起動時に、起動文字列または MySQL 構成ファイルでファイル名を指定することもできます。 起動時にファイル名を指定する場合は、ファイルが存在する必要があります。存在しない場合は、そのようなファイルまたはディレクトリがないことを示す起動エラーが InnoDB によって返されます。

詳細は、セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

innodb_buffer_pool_in_core_file

innodb_buffer_pool_in_core_file 変数を無効にすると、InnoDB バッファープールページが除外され、コアファイルのサイズが小さくなります。 この変数を使用するには、core_file 変数を有効にし、オペレーティングシステムで madvise() に対する MADV_DONTDUMP の POSIX 以外の拡張機能をサポートする必要があります。これは Linux 3.4 以降でサポートされています。 詳細は、セクション15.8.3.7「コアファイルからのバッファープールページの除外」を参照してください。

innodb_buffer_pool_instances

InnoDB のバッファープールが分割される領域の数です。 バッファープールが数 G バイトの範囲にあるシステムでは、バッファープールを個別のインスタンスに分割すると、キャッシュされたページに対して異なるスレッドが読み取りおよび書き込みを行うときの競合が減るため、並列性が向上する場合があります。 バッファープールに格納される各ページまたはバッファープールから読み取られる各ページは、ハッシュ関数を使用して、バッファープールインスタンスのいずれかにランダムに割り当てられます。 各バッファープールは、独自の空きリスト、フラッシュリスト、LRU、およびバッファープールに接続されたその他のすべてのデータ構造を管理し、独自のバッファープール相互排他ロックによって保護されます。

このオプションは、innodb_buffer_pool_size を 1GB 以上に設定する場合にのみ有効になります。 バッファプールの合計サイズは、すべてのバッファプールに分割されます。 最高の効率を得るには、innodb_buffer_pool_instances と innodb_buffer_pool_size の組み合わせを、各バッファープールインスタンスが少なくとも 1G バイトになるように指定します。

32-bit Windows システムのデフォルト値は、次に説明するように、innodb_buffer_pool_size の値によって異なります:

他のすべてのプラットフォームでは、innodb_buffer_pool_size が 1GB 以上の場合、デフォルト値は 8 です。 それ以外の場合、デフォルトは 1 です。

関連情報については、セクション15.8.3.1「InnoDB バッファプールサイズの構成」を参照してください。

innodb_buffer_pool_load_abort

innodb_buffer_pool_load_at_startup または innodb_buffer_pool_load_now によってトリガーされた InnoDB buffer pool コンテンツをリストアするプロセスを中断します。

詳細は、セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

innodb_buffer_pool_load_at_startup

MySQL サーバーの起動時に、以前に保持していたものと同じページをロードすることで、InnoDB buffer pool が自動的に warmed up になるように指定します。 一般に、innodb_buffer_pool_dump_at_shutdown と組み合わせて使用されます。

innodb_buffer_pool_dump_at_shutdown と innodb_buffer_pool_load_at_startup の両方がデフォルトで有効になっています。

詳細は、セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

innodb_buffer_pool_load_now

サーバーの再起動を待たずに一連のデータページをロードすることで、InnoDB buffer pool を即時に warms up します。 ベンチマーク時にキャッシュメモリーを既知の状態に戻したり、レポートやメンテナンスのためにクエリーを実行したあとに、MySQL サーバーの通常のワークロードを再開する準備をしたりする際に役立ちます。

詳細は、セクション15.8.3.6「バッファープールの状態の保存と復元」を参照してください。

innodb_buffer_pool_size

InnoDB がテーブルおよびインデックスのデータをキャッシュするメモリー領域であるバッファープールのサイズ (バイト単位) です。 デフォルト値は 134217728 バイト (128MB) です。 最大値は、CPU アーキテクチャーによって異なります。最大値は、32 ビットシステムでは 4294967295 (2³²-1)、64 ビットシステムでは 18446744073709551615 (2⁶⁴-1) です。 32 ビットシステムでは、CPU アーキテクチャーおよびオペレーティングシステムに、指定された最大値よりも小さい実用的な最大サイズが課されている可能性があります。 バッファープールのサイズが 1G バイトよりも大きい場合に、innodb_buffer_pool_instances を 1 よりも大きい値に設定すると、高負荷のサーバーで拡張性を改善できます。

バッファプールを大きくすると、同じテーブルデータに複数回アクセスするために必要なディスク I/O が少なくなります。 専用データベースサーバーでは、バッファプールサイズをマシンの物理メモリーサイズの 80% に設定できます。 バッファープールサイズを構成するときは、次の潜在的な問題に注意し、必要に応じてバッファープールのサイズをスケールバックする準備をしてください。

バッファープールサイズを増減すると、操作はチャンク単位で実行されます。 チャンクサイズは、innodb_buffer_pool_chunk_size 変数 (デフォルトは 128 MB) によって定義されます。

バッファプールサイズは、常に innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances と等しいか倍数である必要があります。 バッファープールサイズを innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances と等しくない値または倍数に変更すると、バッファープールサイズは innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances と等しいか倍数の値に自動的に調整されます。

innodb_buffer_pool_size は動的に設定できるため、サーバーを再起動せずにバッファプールのサイズを変更できます。 Innodb_buffer_pool_resize_status ステータス変数は、オンラインバッファプールのサイズ変更操作のステータスを報告します。 詳しくはセクション15.8.3.1「InnoDB バッファプールサイズの構成」をご覧ください。

innodb_dedicated_server が有効な場合、innodb_buffer_pool_size 値は明示的に定義されていなければ自動的に構成されます。 詳細は、セクション15.8.12「専用 MySQL Server の自動構成の有効化」を参照してください。

innodb_change_buffer_max_size

buffer pool の合計サイズに対する InnoDB change buffer の最大サイズの割合。 この値は、MySQL サーバーで頻繁に挿入、更新、および削除アクティビティーが発生する場合は大きくし、MySQL サーバーでレポート用に使用されるデータが変更されない場合は小さくするとよいでしょう。 詳細は、セクション15.5.2「変更バッファ」を参照してください。 一般的な I/O チューニングのアドバイスについては、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

innodb_change_buffering

InnoDB がバッファリングの変更 (I/O 操作を連続して実行できるように、セカンダリインデックスへの書き込み操作を遅延させる最適化) を実行するかどうかを指定します。 次のテーブルに、許可される値を示します。 値は数値で指定することもできます。

詳細は、セクション15.5.2「変更バッファ」を参照してください。 一般的な I/O チューニングのアドバイスについては、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

innodb_change_buffering_debug

InnoDB 変更バッファリングのデバッグフラグを設定します。 値 1 を指定すると、変更バッファに対するすべての変更が強制されます。 値 2 を指定すると、マージ時に予期しない終了が発生します。 デフォルト値の 0 は、変更バッファリングデバッグフラグが設定されていないことを示します。 このオプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_checkpoint_disabled

これは、エキスパートによるデバッグのみを目的としたデバッグオプションです。 チェックポイントを無効にして、故意のサーバーイグジットが常に InnoDB リカバリを開始するようにします。 通常は、サーバーの終了後にリカバリが必要な redo ログエントリを書き込む DML 操作を実行する前に、短い間隔でのみ有効にする必要があります。 このオプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_checksum_algorithm

InnoDB tablespaces のディスクブロックに格納されている checksum を生成および検証する方法を指定します。 innodb_checksum_algorithm のデフォルト値は crc32 です。

3.8.0 までのバージョンの MySQL Enterprise Backup は、CRC32 チェックサムを使用するテーブルスペースのバックアップをサポートしていません。 MySQL Enterprise Backup は、CRC32 チェックサムのサポートを 3.8.1 で (いくつかの制限付きで) 追加しています。 詳細は、MySQL Enterprise Backup 3.8.1 の変更履歴を参照してください。

値 innodb は、以前のバージョンの MySQL と下位互換性があります。 値 crc32 では、より高速に、変更されたすべてのブロックのチェックサムを計算し、ディスク読み取りごとにチェックサムをチェックするアルゴリズムが使用されます。 ブロックを一度に 32 ビットスキャンします。これは、ブロックを一度に 8 ビットスキャンする innodb チェックサムアルゴリズムより高速です。 値 none では、ブロックデータに基づいて値が計算されるのではなく、チェックサムフィールドに定数値が書き込まれます。 テーブルスペース内のブロックは、データの変更時に徐々に更新される古いチェックサム値と新しいチェックサム値を混在させて使用できます。テーブルスペース内のブロックが crc32 アルゴリズムを使用するように変更されると、関連付けられたテーブルを以前のバージョンの MySQL で読み取ることはできません。

チェックサムアルゴリズムの厳密な形式では、テーブルスペースで有効だが一致しないチェックサム値が検出されると、エラーが報告されます。 テーブルスペースを初めて設定する場合は、新しいインスタンスでのみ厳密な設定を使用することをお薦めします。 厳密な設定は、ディスク読取り時にすべてのチェックサム値を計算する必要がないため、多少高速です。

次のテーブルに、none、innodb および crc32 オプションの値とそれぞれに対応する厳密な値の違いを示します。none、innodb および crc32 は、指定されたタイプのチェックサム値を各データブロックに書き込みますが、互換性のために、読取り操作中にブロックを検証するときに他のチェックサム値を受け入れます。 厳密な設定も有効なチェックサム値を受け入れますが、一致しない有効なチェックサム値が検出されるとエラーメッセージを出力します。 厳密な形式を使用すると、インスタンス内のすべての InnoDB データファイルが同一の innodb_checksum_algorithm 値で作成される場合に、検証が高速になります。

innodb_cmp_per_index_enabled

INFORMATION_SCHEMA.INNODB_CMP_PER_INDEX テーブルでインデックスごとの圧縮関連の統計を有効にします。 これらの統計は収集にコストがかかる可能性があるため、このオプションは、InnoDB compressed テーブルに関連するパフォーマンスチューニング中に開発、テストまたはレプリカインスタンスでのみ有効にします。

詳細は、セクション26.51.7「INFORMATION_SCHEMA INNODB_CMP_PER_INDEX および INNODB_CMP_PER_INDEX_RESET テーブル」およびセクション15.9.1.4「実行時の InnoDB テーブル圧縮の監視」を参照してください。

innodb_commit_concurrency

同時にコミットできるスレッドの数です。 値を 0 (デフォルト) にすると、任意の数のトランザクションを同時にコミットすることが許可されます。

innodb_commit_concurrency の値は、実行時にゼロからゼロ以外 (またはその逆) に変更できません。 ゼロ以外の値から別のゼロ以外の値に変更することはできます。

innodb_compress_debug

テーブルごとに COMPRESSION 属性を定義せずに、指定された圧縮アルゴリズムを使用してすべてのテーブルを圧縮します。 このオプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

関連情報については、セクション15.9.2「InnoDB ページ圧縮」を参照してください。

innodb_compression_failure_threshold_pct

高コストの compression failures を回避するために MySQL が compressed ページ内でパディングの追加を開始するテーブルの圧縮失敗率のしきい値をパーセンテージで定義します。 このしきい値を超えると、MySQL は、最大で innodb_compression_pad_pct_max で指定されたページサイズの割合まで空き領域の量を動的に調整することで、新しい各圧縮済みページ内に追加の空き領域を残し始めます。 値をゼロにすると、圧縮の効率性をモニターするメカニズムが無効になり、パディングの量が動的に調整されます。

詳細は、セクション15.9.1.6「OLTP ワークロードの圧縮」を参照してください。

innodb_compression_level

InnoDB の圧縮されたテーブルおよびインデックスで使用される zlib 圧縮のレベルを指定します。 値を大きくすると、ストレージデバイス上に収容できるデータ量が多くなりますが、圧縮時の CPU オーバーヘッドも多くなるという犠牲が伴います。 値を小さくすると、ストレージ領域がクリティカルでない場合に、CPU のオーバーヘッドを削減できます。それ以外の場合は、データが特に圧縮可能でないと予測されます。

詳細は、セクション15.9.1.6「OLTP ワークロードの圧縮」を参照してください。

innodb_compression_pad_pct_max

圧縮された各ページ内の空き領域として予約できる最大の割合を指定します。これにより、圧縮されたテーブルまたはインデックスが更新され、データが再度圧縮される可能性があるときに、ページ内のデータおよび変更ログを再編成する余地が得られます。 innodb_compression_failure_threshold_pct がゼロ以外の値に設定され、compression failures のレートがカットオフポイントを通過する場合にのみ適用されます。

詳細は、セクション15.9.1.6「OLTP ワークロードの圧縮」を参照してください。

innodb_concurrency_tickets

同時に InnoDB に入ることができるスレッドの数を決定します。 スレッドが InnoDB に入ろうとしたときに、すでにスレッド数が並列実行の制限に達している場合は、そのスレッドがキューに配置されます。 スレッドが InnoDB に入ることを許可されている場合は、innodb_concurrency_tickets の値と同じ数の「「チケット」」が与えられ、チケットを使い切るまでスレッドは InnoDB に自由に入ることができます。 それ以降は、スレッドが次に InnoDB に入ろうとしたときに、再度並列実行チェックの対象となります (キューに入る対象となる可能性もあります)。 デフォルト値は 5000 です。

innodb_concurrency_tickets 値を小さくすると、1、2 行しか処理する必要のない小規模なトランザクションと、多数の行を処理する大規模なトランザクションが競合する可能性が高くなります。 小さい innodb_concurrency_tickets 値のデメリットは、大規模なトランザクションが完了する前にキューを何度もループする必要があり、これによりタスクの完了に必要な時間が長くなることです。

innodb_concurrency_tickets 値を大きくすると、大規模なトランザクションで (innodb_thread_concurrency で制御される) キューの終了時の位置を待機する時間が短くなり、行を取得する時間が長くなります。 また、大規模なトランザクションでは、タスクを完了するために必要なキューとの間の移動も少なくなります。 innodb_concurrency_tickets 値を大きくする欠点は、同時に実行する大規模なトランザクションの数が非常に多くなることで、小規模なトランザクションが実行されるまでの待機時間が長くなるため、枯渇する可能性がある点です。

ゼロ以外の innodb_thread_concurrency 値では、innodb_concurrency_tickets 値を上下に調整して、大規模なトランザクションと小規模なトランザクションの間の最適なバランスを見つける必要がある場合があります。 SHOW ENGINE INNODB STATUS レポートには、キューを通過する現時点で実行中のトランザクション用に残されているチケットの数が表示されます。 このデータは、INFORMATION_SCHEMA.INNODB_TRX テーブルの TRX_CONCURRENCY_TICKETS カラムから取得することもできます。

詳細は、セクション15.8.4「InnoDB のスレッド並列性の構成」を参照してください。

innodb_data_file_path

InnoDB システムテーブルスペースデータファイルの名前、サイズおよび属性を定義します。 innodb_data_file_path の値を指定しない場合、デフォルトの動作では、12MB を少し超える単一の自動拡張データファイルが ibdata1 という名前で作成されます。

データファイル指定の完全な構文には、ファイル名、ファイルサイズ、autoextend 属性および max 属性が含まれます:

file_name:file_size[:autoextend[:max:max_file_size]]

ファイルサイズは、K、M または G をサイズ値に追加することで、KB、MB または GB 単位で指定します。 データファイルのサイズを KB 単位で指定する場合は、1024 の倍数で指定します。 それ以外の場合、KB 値は最も近いメガバイト (MB) 境界に丸められます。 ファイルサイズの合計は、12MB 以上である必要があります。

その他の構成情報については、システムテーブルスペースデータファイル構成 を参照してください。 サイズ変更の手順は、システムテーブルスペースのサイズ変更 を参照してください。

innodb_data_home_dir

InnoDB system tablespace データファイルのディレクトリパスの共通部分。 デフォルト値は、MySQL の data ディレクトリです。 設定が絶対パスで定義されていないかぎり、この設定は innodb_data_file_path 設定と連結されます。

innodb_data_home_dir の値を指定する場合は、末尾にスラッシュが必要です。 例:

[mysqld]
innodb_data_home_dir = /path/to/myibdata/

この設定は、file-per-table テーブルスペースの場所には影響しません。

関連情報については、セクション15.8.1「InnoDB の起動構成」を参照してください。

innodb_ddl_log_crash_reset_debug

DDL ログクラッシュインサーションカウンタを 1 にリセットするには、このデバッグオプションを有効にします。 このオプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_deadlock_detect

このオプションは、デッドロック検出を無効にするために使用します。 同時実行性の高いシステムでは、多数のスレッドが同じロックを待機している場合、デッドロック検出によって速度が低下する可能性があります。 デッドロック検出を無効にし、デッドロック発生時のトランザクションロールバックの innodb_lock_wait_timeout 設定に依存する方が効率的な場合があります。

関連情報については、セクション15.7.5.2「デッドロック検出」を参照してください。

innodb_dedicated_server

innodb_dedicated_server が有効な場合、InnoDB は次の変数を自動的に構成します:

MySQL インスタンスが、使用可能なすべてのシステムリソースを使用できる専用サーバーに存在する場合にのみ、innodb_dedicated_server を有効にすることを検討してください。 MySQL インスタンスが他のアプリケーションとシステムリソースを共有している場合、innodb_dedicated_server を有効にすることはお薦めしません。

詳細は、セクション15.8.12「専用 MySQL Server の自動構成の有効化」を参照してください。

innodb_default_row_format

innodb_default_row_format オプションは、InnoDB テーブルおよびユーザー作成一時テーブルのデフォルトの行形式を定義します。 デフォルト設定は DYNAMIC です。 許可されるその他の値は、COMPACT および REDUNDANT です。 system tablespace での使用がサポートされていない COMPRESSED 行フォーマットは、デフォルトとして定義できません。

新しく作成されたテーブルでは、ROW_FORMAT オプションが明示的に指定されていない場合、または ROW_FORMAT=DEFAULT が使用されている場合に、innodb_default_row_format で定義された行形式が使用されます。

ROW_FORMAT オプションが明示的に指定されていない場合、または ROW_FORMAT=DEFAULT が使用されている場合は、テーブルを再構築する操作によって、テーブルの行形式も innodb_default_row_format で定義された形式に暗黙的に変更されます。 詳細は、テーブルの行形式の定義を参照してください。

クエリーを処理するためにサーバーによって作成された内部 InnoDB 一時テーブルは、innodb_default_row_format の設定に関係なく、DYNAMIC 行形式を使用します。

innodb_directories

起動時にテーブルスペースファイルをスキャンするディレクトリを定義します。 このオプションは、サーバーがオフラインのときにテーブルスペースファイルを新しい場所に移動またはリストアする場合に使用します。 また、絶対パスを使用して作成されたテーブルスペースファイル、またはデータディレクトリの外部にあるテーブルスペースファイルのディレクトリを指定するためにも使用されます。

クラッシュリカバリ中のテーブルスペースの検出は、redo ログで参照されるテーブルスペースを識別するために innodb_directories 設定に依存します。 詳細は、クラッシュリカバリ中のテーブルスペースの検出を参照してください。

innodb_data_home_dir、innodb_undo_directory および datadir によって定義されたディレクトリは、innodb_directories オプションが明示的に指定されているかどうかに関係なく、起動時にスキャンするディレクトリのリストを作成するときに innodb_directories 引数値に自動的に追加されます。

innodb_directories は、起動コマンドまたは MySQL オプションファイルでオプションとして指定できます。 一部のコマンドインタプリタではセミコロン (;) は特殊文字として解釈されるため、引数値の前後に引用符が使用されます。 (たとえば UNIX シェルでは、これはコマンド終端記号として扱われます。)

起動コマンド:

mysqld --innodb-directories="directory_path_1;directory_path_2"

MySQL オプションファイル:

[mysqld]
innodb_directories="directory_path_1;directory_path_2"

ワイルドカード式は、ディレクトリの指定には使用できません。

innodb_directories スキャンは、指定されたディレクトリのサブディレクトリも走査します。 重複するディレクトリおよびサブディレクトリは、スキャンされるディレクトリのリストから破棄されます。

詳細は、セクション15.6.3.6「サーバーがオフラインのときのテーブルスペースファイルの移動」を参照してください。

innodb_disable_sort_file_cache

マージソート一時ファイルのオペレーティングシステムファイルシステムキャッシュを無効にします。 その結果、このようなファイルが O_DIRECT の同等のものとともに開きます。

innodb_doublewrite

innodb_doublewrite 変数は、二重書込みバッファを有効にするかどうかを制御します。 ほとんどの場合、デフォルトで有効になっています。 二重書込みバッファを無効にするには、innodb_doublewrite を 0 に設定するか、--skip-innodb-doublewrite でサーバーを起動します。 たとえば、ベンチマークの実行時などのように、データ整合性よりもパフォーマンスに関心がある場合は、二重書込みバッファを無効にすることを検討してください。

二重書き込みバッファーがアトミック書き込みをサポートする Fusion-io デバイス上にある場合、二重書き込みバッファーは自動的に無効になり、代わりに Fusion-io アトミック書き込みを使用してデータファイル書き込みが実行されます。 ただし、innodb_doublewrite 設定はグローバルであることに注意してください。 二重書き込みバッファーが無効になっている場合、Fusion-io ハードウェア上に存在しないデータファイルを含むすべてのデータファイルに対して無効になります。 この機能は Fusion-io ハードウェアでのみサポートされ、Linux の Fusion-io NVMFS でのみ有効になります。 この機能を最大限に活用するには、O_DIRECT の innodb_flush_method 設定をお薦めします。

関連情報については、セクション15.6.4「二重書き込みバッファー」を参照してください。

innodb_doublewrite_batch_size

バッチで書き込む二重書込みページの数を定義します。

詳細は、セクション15.6.4「二重書き込みバッファー」を参照してください。

innodb_doublewrite_dir

二重書込みファイルのディレクトリを定義します。 ディレクトリが指定されていない場合、二重書込みファイルが innodb_data_home_dir ディレクトリに作成され、指定されていない場合はデータディレクトリにデフォルト設定されます。

詳細は、セクション15.6.4「二重書き込みバッファー」を参照してください。

innodb_doublewrite_files

二重書込みファイルの数を定義します。 デフォルトでは、バッファープールインスタンスごとに 2 つの二重書き込みファイルが作成されます。

少なくとも 2 つの二重書込みファイルがあります。 二重書込みファイルの最大数は、バッファプールインスタンスの 2 倍です。 (バッファープールインスタンスの数は、innodb_buffer_pool_instances 変数によって制御されます。)

詳細は、セクション15.6.4「二重書き込みバッファー」を参照してください。

innodb_doublewrite_pages

バッチ書込みのスレッド当たりの二重書込みページの最大数を定義します。 値が指定されていない場合、innodb_doublewrite_pages は innodb_write_io_threads 値に設定されます。

詳細は、セクション15.6.4「二重書き込みバッファー」を参照してください。

innodb_extend_and_initialize

Linux システムの file-per-table テーブルスペースおよび一般テーブルスペースへの領域の割当て方法を制御します。

有効にすると、InnoDB は新しく割り当てられたページに NULL を書き込みます。 無効にすると、領域は posix_fallocate() コールを使用して割り当てられます。このコールは、物理的に NULL を書き込まずに領域を予約します。

詳細は、セクション15.6.3.8「Linux でのテーブルスペースの領域割当ての最適化」を参照してください。

innodb_fast_shutdown

InnoDB のシャットダウンモードです。 値が 0 の場合、InnoDB は、停止前に slow shutdown、完全な purge および変更バッファのマージを実行します。 この値を 1 (デフォルト) にすると、InnoDB はシャットダウン時に、これらの操作をスキップします。このプロセスは、高速シャットダウンと呼ばれます。 この値を 2 にすると、InnoDB は MySQL がクラッシュした場合と同様に、そのログをフラッシュし、コールドシャットダウンを実行します。コミットされていないトランザクションは失われませんが、クラッシュリカバリ操作によって次回の起動時間が長くなります。

低速シャットダウンには数分間かかる可能性があり、大量のデータがバッファーに存在する極端なケースでは、数時間かかる可能性もあります。 MySQL のメジャーリリース間でアップグレードまたはダウングレードを行う前には、アップグレードプロセスによってファイル形式が更新される場合に備えて、すべてのデータファイルが完全に準備されるように、低速シャットダウン技術を使用してください。

データが破損するリスクがある場合に、完全な最速のシャットダウンを行うには、緊急事態またはトラブルシューティングの状況で innodb_fast_shutdown=2 を使用してください。

innodb_fil_make_page_dirty_debug

デフォルトでは、innodb_fil_make_page_dirty_debug をテーブルスペースの ID に設定すると、テーブルスペースの最初のページがすぐに使用済になります。 innodb_saved_page_number_debug がデフォルト以外の値に設定されている場合、innodb_fil_make_page_dirty_debug を設定すると、指定したページがダーティになります。 innodb_fil_make_page_dirty_debug オプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_file_per_table

innodb_file_per_table が有効な場合、テーブルはデフォルトで file-per-table テーブルスペースに作成されます。 無効にすると、デフォルトでシステムテーブルスペースにテーブルが作成されます。 file-per-table テーブルスペースについては、セクション15.6.3.2「File-Per-Table テーブルスペース」 を参照してください。 InnoDB システムテーブルスペースの詳細は、セクション15.6.3.1「システムテーブルスペース」 を参照してください。

innodb_file_per_table 変数は、実行時に SET GLOBAL ステートメントを使用して構成するか、起動時にコマンドラインで指定するか、またはオプションファイルで指定できます。 実行時の構成には、グローバルシステム変数を設定するのに十分な権限 (セクション5.1.9.1「システム変数権限」 を参照) が必要で、すべての接続の操作にすぐに影響します。

file-per-table テーブルスペースに存在するテーブルが切り捨てられるか削除されると、解放された領域がオペレーティングシステムに戻されます。 システムテーブルスペースに存在するテーブルの切捨てまたは削除では、システムテーブルスペースの領域のみが解放されます。 システムテーブルスペースのデータファイルは縮小しないため、システムテーブルスペースの空き領域は InnoDB データに再度使用できますが、オペレーティングシステムには戻されません。

innodb_file_per-table 設定は、一時テーブルの作成には影響しません。 MySQL 8.0.14 では、一時テーブルはセッション一時テーブルスペースに作成され、その前にグローバル一時テーブルスペースに作成されます。 セクション15.6.3.5「一時テーブルスペース」を参照してください。

innodb_fill_factor

InnoDB では、インデックスの作成または再構築時にバルクロードが実行されます。 このインデックス作成方法は、「「ソートされたインデックス構築」」と呼ばれます。

innodb_fill_factor では、ソートされたインデックスの作成時に入力される各 B ツリーページ上の領域の割合が定義され、将来のインデックスの増加のために予約されている残りの領域が使用されます。 たとえば、innodb_fill_factor を 80 に設定すると、将来のインデックス増加のために各 B ツリーページの領域の 20% が予約されます。 実際の割合は異なる場合があります。 innodb_fill_factor 設定は、強い制限ではなくヒントとして解釈されます。

innodb_fill_factor を 100 に設定すると、クラスタ化されたインデックスページの領域の 1/16 は将来のインデックスの増加に備えて解放されます。

innodb_fill_factor は、B ツリーリーフページと非リーフページの両方に適用されます。 TEXT または BLOB エントリに使用される外部ページには適用されません。

詳細は、セクション15.6.2.3「ソートされたインデックス構築」を参照してください。

innodb_flush_log_at_timeout

N 秒ごとにログを書き込み、フラッシュします。innodb_flush_log_at_timeout では、フラッシュを減らし、バイナリロググループのコミットのパフォーマンスへの影響を回避するために、フラッシュ間のタイムアウト期間を増やすことができます。 innodb_flush_log_at_timeout のデフォルト設定は 1 秒に 1 回です。

innodb_flush_log_at_trx_commit

commit 操作に対する厳密な ACID コンプライアンスと、コミット関連の I/O 操作がバッチで再配置および実行される場合に可能なパフォーマンスのバランスを制御します。 デフォルト値を変更することでパフォーマンスを向上できますが、クラッシュ時にトランザクションが失われる可能性があります。

トランザクションで InnoDB が使用されるレプリケーションセットアップの持続性および一貫性を保つ場合:

予期しない停止に対して最も回復可能なレプリカの設定の組合せの詳細は、セクション17.4.2「レプリカの予期しない停止の処理」 を参照してください。

innodb_flush_method

InnoDB data files および log files への flush データに使用される方法を定義します。これは I/O スループットに影響する可能性があります。

Unix に似たシステムでは、デフォルト値は fsync です。 Windows では、デフォルト値は unbuffered です。

Unix に似たシステムの innodb_flush_method オプションには、次のものがあります:

Windows システム用の innodb_flush_method オプションには、次のものがあります:

各設定がパフォーマンスに与える影響は、ハードウェア構成およびワークロードによって異なります。 使用する設定を決定したり、デフォルト設定のままにするかどうかを決定したりするには、特定の構成でベンチマークを実施します。 設定ごとに fsync() 呼び出しの全体数を確認するには、Innodb_data_fsyncs ステータス変数を調査します。 ワークロードに読み取り操作と書き込み操作を混在させると、一部の設定での実行が影響を受ける可能性があります。 たとえば、ハードウェア RAID コントローラとバッテリバックアップ式書き込みキャッシュを備えたシステムでは、O_DIRECT は、InnoDB バッファープールとオペレーティングシステムのファイルシステムキャッシュの間の二重バッファリングを回避するのに役立ちます。 InnoDB のデータファイルとログファイルが SAN 上に配置されている一部のシステムでは、大部分の SELECT ステートメントを含む読み取り負荷の高いワークロードで、デフォルト値または O_DSYNC の速度が速くなる可能性があります。 このパラメータは、必ず、本番環境が反映されたハードウェアおよびワークロードでテストしてください。 一般的な I/O チューニングのアドバイスについては、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

innodb_dedicated_server が有効な場合、innodb_flush_method 値は明示的に定義されていなければ自動的に構成されます。 詳細は、セクション15.8.12「専用 MySQL Server の自動構成の有効化」を参照してください。

innodb_flush_neighbors

flushing で、InnoDB buffer pool のページが同じ extent の他の dirty pages もフラッシュするかどうかを指定します。

テーブルデータが従来の HDD ストレージデバイスに格納されている場合は、1 回の操作でこのような隣接ページをフラッシュすると、さまざまな時間に個々のページをフラッシュする場合と比較して、(主にディスクシーク操作の) I/O オーバーヘッドが削減されます。 SSD に格納されているテーブルデータの場合、シーク時間は重要な要因ではなく、このオプションを 0 に設定して書込み操作を分散できます。 関連情報については、セクション15.8.3.5「バッファープールのフラッシュの構成」を参照してください。

innodb_flush_sync

innodb_flush_sync 変数はデフォルトで有効になっており、checkpoints で発生する I/O アクティビティのバースト中に innodb_io_capacity 設定が無視されます。 innodb_io_capacity 設定で定義された I/O レートに準拠するには、innodb_flush_sync を無効にします。

innodb_flush_sync 変数の構成の詳細は、セクション15.8.7「InnoDB I/O Capacity の構成」 を参照してください。

innodb_flushing_avg_loops

InnoDB が以前に計算されたフラッシュ状態のスナップショットを保持し、adaptive flushing が workloads の変更にどのくらい迅速に応答するかを制御する反復の数。 この値を大きくすると、ワークロードが変化するにつれて、フラッシュ操作の速度が円滑かつ徐々に変化します。 この値を小さくすると、適応型フラッシュがワークロードの変化にすばやく適応します。これにより、ワークロードが突然に増減した場合に、フラッシュアクティビティーが急増する可能性があります。

関連情報については、セクション15.8.3.5「バッファープールのフラッシュの構成」を参照してください。

innodb_force_load_corrupted

破損としてマークされたテーブルを起動時に InnoDB がロードできるようにします。 トラブルシューティング時に、何も対処しなければアクセスできないデータをリカバリする際にのみ使用してください。 トラブルシューティングが完了したら、この設定を無効にしてサーバーを再起動します。

innodb_force_recovery

クラッシュリカバリモードです。一般に、重大なトラブルシューティングの状況でのみ変更されます。 指定可能な値は 0 から 6 までです。 これらの値の意味および innodb_force_recovery に関する重要な情報については、セクション15.21.2「InnoDB のリカバリの強制的な実行」を参照してください。

innodb_fsync_threshold

デフォルトでは、InnoDB が新しいログファイルやテーブルスペースファイルなどの新しいデータファイルを作成すると、ファイルはディスクにフラッシュされる前にオペレーティングシステムキャッシュに完全に書き込まれるため、大量のディスク書込みアクティビティが一度に発生する可能性があります。 オペレーティングシステムキャッシュから定期的にデータを強制的に小さいフラッシュするには、innodb_fsync_threshold 変数を使用してしきい値をバイト単位で定義します。 バイトしきい値に達すると、オペレーティングシステムキャッシュの内容がディスクにフラッシュされます。 デフォルト値の 0 では、デフォルトの動作が強制されます。つまり、ファイルがキャッシュに完全に書き込まれた後にのみ、データがディスクにフラッシュされます。

複数の MySQL インスタンスが同じストレージデバイスを使用している場合は、より小さい定期的なフラッシュを強制的に実行するためのしきい値を指定すると有益です。 たとえば、新しい MySQL インスタンスとそれに関連付けられたデータファイルを作成すると、ディスク書込みアクティビティが大きくなり、同じストレージデバイスを使用する他の MySQL インスタンスのパフォーマンスが低下する可能性があります。 しきい値を構成すると、書込みアクティビティでのこのようなサージの回避に役立ちます。

innodb_ft_aux_table

FULLTEXT インデックスを含む InnoDB テーブルの修飾名を指定します。 この変数は診断のために使用され、実行時にのみ設定できます。 例:

SET GLOBAL innodb_ft_aux_table = 'test/t1';

この変数を db_name/table_name 形式の名前に設定すると、INFORMATION_SCHEMA テーブル INNODB_FT_INDEX_TABLE, INNODB_FT_INDEX_CACHE, INNODB_FT_CONFIG, INNODB_FT_DELETED および INNODB_FT_BEING_DELETED に、指定したテーブルの検索インデックスに関する情報が表示されます。

詳細は、セクション15.15.4「InnoDB INFORMATION_SCHEMA FULLTEXT インデックステーブル」を参照してください。

innodb_ft_cache_size

InnoDB FULLTEXT 検索インデックスキャッシュに割り当てられたメモリー (バイト単位)。これは、InnoDB FULLTEXT インデックスの作成時にメモリー内に解析済ドキュメントを保持します。 innodb_ft_cache_size のサイズ制限に達すると、インデックスの挿入および更新のみがディスクにコミットされます。innodb_ft_cache_size では、キャッシュサイズがテーブルごとに定義されます。 すべてのテーブルにグローバルな制限を設定する方法については、innodb_ft_total_cache_size を参照してください。

詳細は、InnoDB 全文インデックスキャッシュを参照してください。

innodb_ft_enable_diag_print

追加の全文検索 (FTS) 診断の出力を有効にするかどうかを指定します。 このオプションは主に高度な FTS デバッグを目的としており、ほとんどのユーザーにとって重要ではありません。 出力はエラーログに記録され、次のような情報が含まれています。

innodb_ft_enable_stopword

インデックスの作成時に、一連のストップワードが InnoDB の FULLTEXT インデックスに関連付けられることを指定します。 innodb_ft_user_stopword_table オプションが設定されている場合は、そのテーブルからストップワードが取得されます。 そうでなければ、innodb_ft_server_stopword_table オプションが設定されている場合は、そのテーブルからストップワードが取得されます。 それ以外の場合は、組み込みのデフォルトストップワードセットが使用されます。

詳細は、セクション12.10.4「全文ストップワード」を参照してください。

innodb_ft_max_token_size

InnoDB FULLTEXT インデックスに格納される単語の最大文字長。 この値に制限を設定すると、実在の単語ではなく、検索語句になる可能性の低い英字の任意のコレクションや長いキーワードが省略されることで、インデックスのサイズが削減されるため、クエリーの速度が上がります。

詳細は、セクション12.10.6「MySQL の全文検索の微調整」を参照してください。

innodb_ft_min_token_size

InnoDB FULLTEXT インデックスに格納される単語の最小長。 この値を大きくすると、英語の 「a」 や 「to」 などの検索コンテキストで重要ではない一般的な単語が省略されるため、インデックスのサイズが減り、クエリーが高速化されます。 内容で CJK (中国語、日本語、韓国語) 文字セットが使用されている場合は、値 1 を指定します。

詳細は、セクション12.10.6「MySQL の全文検索の微調整」を参照してください。

innodb_ft_num_word_optimize

InnoDB の FULLTEXT インデックスでの各 OPTIMIZE TABLE 操作時に処理される単語数です。 全文検索インデックスを含むテーブルへの一括挿入または一括更新操作では、すべての変更を組み込むために大量のインデックスのメンテナンスが必要となる可能性があるため、それぞれが最後に終了した場所から再開する一連の OPTIMIZE TABLE ステートメントを実行するとよいでしょう。

詳細は、セクション12.10.6「MySQL の全文検索の微調整」を参照してください。

innodb_ft_result_cache_limit

全文検索クエリーまたはスレッド当たりの InnoDB 全文検索クエリーの結果キャッシュ制限 (バイト単位で定義)。 中間および最終的な InnoDB 全文検索クエリー結果はメモリー内で処理されます。 innodb_ft_result_cache_limit を使用して全文検索のクエリー結果キャッシュにサイズ制限を設定し、InnoDB 全文検索のクエリー結果が非常に大きい場合 (数百万行や数百万行など) にメモリーを過剰に消費しないようにします。 全文検索クエリーの処理時に、必要に応じてメモリーが割り当てられます。 結果のキャッシュサイズ制限に達すると、クエリーで最大限に許可されるメモリー量を超えたことを示すエラーが返されます。

すべてのプラットフォームタイプおよびビットサイズに対する innodb_ft_result_cache_limit の最大値は、2**32-1 です。

innodb_ft_server_stopword_table

このオプションは、すべての InnoDB テーブルに対応した独自の InnoDB の FULLTEXT インデックスストップワードリストを指定する際に使用されます。 特定の InnoDB テーブルに独自のストップワードリストを構成するには、innodb_ft_user_stopword_table を使用します。

db_name/table_name の形式で、innodb_ft_server_stopword_table をストップワードリストを含むテーブルの名前に設定します。

innodb_ft_server_stopword_table を構成する前に、ストップワードテーブルが存在する必要があります。FULLTEXT インデックスを作成する前に、innodb_ft_enable_stopword を有効にし、innodb_ft_server_stopword_table オプションを構成する必要があります。

ストップワードテーブルは、value という名前の単一の VARCHAR カラムを含む InnoDB テーブルである必要があります。

詳細は、セクション12.10.4「全文ストップワード」を参照してください。

innodb_ft_sort_pll_degree

search index の構築時に InnoDB FULLTEXT インデックスのテキストをインデックス付けおよびトークン化するためにパラレルで使用されるスレッドの数。

関連情報は、セクション15.6.2.4「InnoDB FULLTEXT インデックス」 および innodb_sort_buffer_size を参照してください。

innodb_ft_total_cache_size

すべてのテーブルの InnoDB 全文検索インデックスキャッシュに割り当てられた合計メモリー (バイト)。 FULLTEXT 検索インデックスを使用して多数のテーブルを作成すると、使用可能なメモリーの大部分が消費される可能性があります。innodb_ft_total_cache_size では、過剰なメモリー消費を回避するために、すべての全文検索インデックスに対してグローバルメモリー制限を定義します。 インデックス操作によってグローバル制限に達すると、強制同期がトリガーされます。

詳細は、InnoDB 全文インデックスキャッシュを参照してください。

innodb_ft_user_stopword_table

このオプションは、特定のテーブルに独自の InnoDB の FULLTEXT インデックスストップワードリストを指定する際に使用されます。 すべての InnoDB テーブル用に独自のストップワードリストを構成するには、innodb_ft_server_stopword_table を使用します。

db_name/table_name の形式で、innodb_ft_user_stopword_table をストップワードリストを含むテーブルの名前に設定します。

innodb_ft_user_stopword_table を構成する前に、ストップワードテーブルが存在する必要があります。FULLTEXT インデックスを作成する前に、innodb_ft_enable_stopword を有効にし、innodb_ft_user_stopword_table を構成する必要があります。

ストップワードテーブルは、value という名前の単一の VARCHAR カラムを含む InnoDB テーブルである必要があります。

詳細は、セクション12.10.4「全文ストップワード」を参照してください。

innodb_idle_flush_pct

InnoDB がアイドル状態の場合のページフラッシュを制限します。 innodb_idle_flush_pct 値は、InnoDB で使用可能な I/O 操作数/秒を定義する innodb_io_capacity 設定の割合です。 詳細は、アイドル期間中のバッファフラッシュの制限を参照してください。

innodb_io_capacity

innodb_io_capacity 変数は、buffer pool からの flushing ページや change buffer からのデータのマージなど、InnoDB バックグラウンドタスクで使用可能な秒当たりの I/O 操作数 (IOPS) を定義します。

innodb_io_capacity 変数の構成の詳細は、セクション15.8.7「InnoDB I/O Capacity の構成」 を参照してください。

innodb_io_capacity_max

フラッシュアクティビティが遅れている場合、InnoDB は innodb_io_capacity 変数で定義されているよりも高い速度の I/O 操作/秒 (IOPS) で、より積極的にフラッシュできます。 innodb_io_capacity_max 変数は、このような状況で InnoDB バックグラウンドタスクによって実行される IOPS の最大数を定義します。

innodb_io_capacity_max 変数の構成の詳細は、セクション15.8.7「InnoDB I/O Capacity の構成」 を参照してください。

innodb_limit_optimistic_insert_debug

B-tree ページ当たりのレコード数を制限します。 デフォルト値 0 は、制限が課されないことを意味します。 このオプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_lock_wait_timeout

行ロックが解除されるまで InnoDB トランザクションが待機する時間の長さ (秒単位) です。 デフォルト値は 50 秒です。 別の InnoDB トランザクションでロックされている行へのアクセスを試みるトランザクションは、行への書き込みアクセスを最大でこの秒数間待機してから、次のエラーを発行します。

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

ロック待機のタイムアウトが発生すると、(トランザクション全体ではなく) 現在のステートメントがロールバックされます。 トランザクション全体をロールバックするには、--innodb-rollback-on-timeout オプションを使用してサーバーを起動します。 セクション15.21.4「InnoDB のエラー処理」も参照してください。

高度にインタラクティブなアプリケーションまたは OLTP システムでは、ユーザーのフィードバックをすばやく表示したり、あとで処理するために更新をキューに入れたりするために、この値を小さくするとよいでしょう。 長時間実行されるバックエンド操作 (その他の大規模な挿入操作や更新操作が完了するまで待機するデータウェアハウスでの変換ステップなど) では、この値を大きくするとよいでしょう。

innodb_lock_wait_timeout は、InnoDB の行ロックに適用されます。 MySQL のテーブルロックは InnoDB 内部では発生せず、このタイムアウトはテーブルロックの待機には適用されません。

InnoDB ではデッドロックが即時に検出され、デッドロックされたトランザクションのいずれかがロールバックされるため、innodb_deadlock_detect が有効な場合 (デフォルト)、ロック待機タイムアウト値は deadlocks には適用されません。 innodb_deadlock_detect が無効になっている場合、InnoDB はデッドロック発生時のトランザクションロールバックを innodb_lock_wait_timeout に依存します。 セクション15.7.5.2「デッドロック検出」を参照してください。

innodb_lock_wait_timeout は、実行時に SET GLOBAL または SET SESSION ステートメントとともに設定できます。 GLOBAL 設定を変更するには、グローバルシステム変数を設定するのに十分な権限 (セクション5.1.9.1「システム変数権限」 を参照) が必要であり、その後接続するすべてのクライアントの操作に影響します。 任意のクライアントが innodb_lock_wait_timeout の SESSION 設定を変更でき、そのクライアントのみが影響を受けます。

innodb_log_buffer_size

ディスク上のログファイルに書き込む際に InnoDB で使用されるバッファーのサイズ (バイト単位) です。 デフォルトは 16M バイトです。 大規模な log buffer では、トランザクション commit の前にログをディスクに書き込むことなく、大規模な transactions を実行できます。 したがって、多数の行を更新、挿入、または削除するトランザクションの場合、ログバッファーを大きくすると、ディスク I/O を節約できます。 関連情報については、メモリー構成,およびセクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。 一般的な I/O チューニングのアドバイスについては、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

innodb_log_checkpoint_fuzzy_now

InnoDB にファジーチェックポイントの書込みを強制するには、このデバッグオプションを有効にします。 このオプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_log_checkpoint_now

InnoDB にチェックポイントの書込みを強制するには、このデバッグオプションを有効にします。 このオプションは、デバッグサポートが WITH_DEBUG CMake オプションを使用してコンパイルされている場合にのみ使用できます。

innodb_log_checksums

redo ログページのチェックサムを有効または無効にします。

innodb_log_checksums=ON では、redo ログページの CRC-32C チェックサムアルゴリズムを有効にします。 innodb_log_checksums が無効な場合、redo ログページのチェックサムフィールドの内容は無視されます。

redo ログヘッダーページおよび redo ログチェックポイントページのチェックサムは無効化されません。

innodb_log_compressed_pages

re-compressed pages のイメージを redo log に書き込むかどうかを指定します。 圧縮されたデータが変更されると、再圧縮が発生する場合があります。

innodb_log_compressed_pages は、リカバリ時に異なるバージョンの zlib 圧縮アルゴリズムが使用された場合に発生する可能性がある破損を防ぐために、デフォルトで有効になっています。 zlib のバージョンが変更されないことが確実な場合は、innodb_log_compressed_pages を無効にして、圧縮データを変更するワークロードの redo ログ生成を減らすことができます。

innodb_log_compressed_pages の有効化または無効化の影響を測定するには、同じワークロードで両方の設定の redo ログ生成を比較します。 redo ログ生成の測定オプションには、SHOW ENGINE INNODB STATUS 出力の LOG セクションでの Log sequence number (LSN) の監視、または redo ログファイルに書き込まれたバイト数の Innodb_os_log_written ステータスの監視が含まれます。

関連情報については、セクション15.9.1.6「OLTP ワークロードの圧縮」を参照してください。

innodb_log_file_size

ロググループ内の各ログファイルのサイズ (バイト単位) です。 ログファイルを結合したサイズ (innodb_log_file_size * innodb_log_files_in_group) は、512G バイトよりもわずかに小さい最大値を上回ることができません。 たとえば、255 GB のログファイルのペアは制限に近づいていますが、それを超えていません。 デフォルト値は 48M バイトです。

一般に、ログファイルの合計サイズは、サーバーがワークロードアクティビティのピークおよびトラブルをスムーズにできる十分な大きさである必要があります。これは、書込みアクティビティを 1 時間以上処理するための十分な redo ログ領域があることを意味することがよくあります。 この値が大きいほど、バッファプールで必要なチェックポイントフラッシュアクティビティが少なくなり、ディスク I/O が節約されます。 ログファイルが大きいほど、crash recovery も遅くなります。

最小の innodb_log_file_size は 4MB です。

関連情報については、redo ログファイル構成を参照してください。 一般的な I/O チューニングのアドバイスについては、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

innodb_dedicated_server が有効な場合、innodb_log_file_size 値は明示的に定義されていなければ自動的に構成されます。 詳細は、セクション15.8.12「専用 MySQL Server の自動構成の有効化」を参照してください。

innodb_log_files_in_group

ロググループ内のログファイルの数です。 InnoDB はファイルに輪状に書き込みをします。 デフォルト (推奨) 値は 2 です。 ファイルの場所は、innodb_log_group_home_dir によって指定されます。 ログファイルを結合したサイズ (innodb_log_file_size * innodb_log_files_in_group) は、最大で 512G バイトにすることができます。

関連情報については、redo ログファイル構成を参照してください。

innodb_log_group_home_dir

InnoDB の Redo ログファイルへのディレクトリパスです。この数は、innodb_log_files_in_group で指定されます。 どの InnoDB ログ変数も指定しない場合は、デフォルトで、MySQL データディレクトリ内に ib_logfile0 および ib_logfile1 という名前の 2 つのファイルが作成されます。 ログファイルのサイズは、innodb_log_file_size システム変数によって指定されます。

関連情報については、redo ログファイル構成を参照してください。

innodb_log_spin_cpu_abs_lwm

フラッシュされた redo の待機中にユーザースレッドがスピンしなくなる CPU 使用率の最小量を定義します。 この値は、CPU コア使用率の合計として表されます。 たとえば、80 のデフォルト値は、単一の CPU コアの 80% です。 マルチコアプロセッサを搭載したシステムでは、150 の値は、1 つの CPU コアの 100% 使用率と 2 つ目の CPU コアの 50% 使用率を表します。

関連情報については、セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。

innodb_log_spin_cpu_pct_hwm

フラッシュされた redo の待機中にユーザースレッドがスピンしなくなる CPU 使用率の最大量を定義します。 この値は、すべての CPU コアの合計処理能力の割合として表されます。 デフォルト値は 50% です。 たとえば、2 つの CPU コアの 100% 使用率は、4 つの CPU コアを持つサーバーでの CPU 処理能力の合計の 50% です。

innodb_log_spin_cpu_pct_hwm 変数は、プロセッサアフィニティを考慮します。 たとえば、サーバーに 48 個のコアがあり、mysqld プロセスが 4 個の CPU コアにのみ固定されている場合、他の 44 個の CPU コアは無視されます。

関連情報については、セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。

innodb_log_wait_for_flush_spin_hwm

フラッシュされた redo の待機中にユーザースレッドがスピンしなくなる最大平均ログフラッシュ時間を定義します。 デフォルト値は 400 マイクロ秒です。

関連情報については、セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。

innodb_log_write_ahead_size

redo ログの先行書込みブロックサイズをバイト単位で定義します。 「read-on-write」 を回避するには、オペレーティングシステムまたはファイルシステムのキャッシュブロックサイズと一致するように innodb_log_write_ahead_size を設定します。 デフォルト設定は 8192 バイトです。 読取り/書込みは、redo ログの先行書込みブロックサイズとオペレーティングシステムまたはファイルシステムのキャッシュブロックサイズが一致しないために、redo ログブロックがオペレーティングシステムまたはファイルシステムに完全にキャッシュされない場合に発生します。

innodb_log_write_ahead_size の有効な値は、InnoDB ログファイルのブロックサイズ (2 ⁿ) の倍数です。 最小値は、InnoDB ログファイルのブロックサイズ (512) です。 最小値が指定されている場合、ライトアヘッドは発生しません。 最大値は innodb_page_size 値と同じです。 innodb_log_write_ahead_size に innodb_page_size 値より大きい値を指定すると、innodb_log_write_ahead_size 設定は innodb_page_size 値に切り捨てられます。

オペレーティングシステムまたはファイルシステムのキャッシュブロックサイズに対する innodb_log_write_ahead_size 値の設定が低すぎると、「read-on-write」 が発生します。 値を高く設定しすぎると、一度に複数のブロックが書き込まれるため、ログファイル書込みの fsync パフォーマンスにわずかな影響を与える可能性があります。

関連情報については、セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。

innodb_log_writer_threads

ログバッファからシステムバッファに redo ログレコードを書き込み、システムバッファを redo ログファイルにフラッシュするための専用のログライタースレッドを有効にします。 専用ログライタースレッドを使用すると、同時実行性の高いシステムのパフォーマンスを向上させることができますが、同時実行性の低いシステムでは、専用ログライタースレッドを無効にすると、パフォーマンスが向上します。

詳細は、セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。

innodb_lru_scan_depth

InnoDB のバッファープールでのフラッシュ操作のアルゴリズムおよびヒューリスティクスに影響を与えるパラメータです。 主に、I/O インテンシブなワークロードを調整するパフォーマンスの専門家が関心を持つものです。 バッファプールインスタンスごとに、フラッシュする dirty pages を検索するページクリーナスレッドスキャンをバッファプール LRU ページにリストする距離を指定します。 これは、1 秒に 1 回実行されるバックグラウンド操作です。

デフォルトより小さい設定は、通常、ほとんどのワークロードに適しています。 必要以上の値を指定すると、パフォーマンスに影響する可能性があります。 通常のワークロードでスペア I/O 容量がある場合のみ、値を増やすことを検討してください。 逆に、書込み集中型のワークロードが I/O の容量を満たしている場合は、特に大きなバッファプールの場合に値を減らします。

innodb_lru_scan_depth をチューニングする場合は、小さい値から始めて、ゼロの空きページが表示されることがほとんどないという目標で設定を上方に構成します。 また、innodb_lru_scan_depth * innodb_buffer_pool_instances は毎秒ページクリーナスレッドによって実行される作業量を定義するため、バッファプールインスタンスの数を変更するときに innodb_lru_scan_depth を調整することを検討してください。

関連情報については、セクション15.8.3.5「バッファープールのフラッシュの構成」を参照してください。 一般的な I/O チューニングのアドバイスについては、セクション8.5.8「InnoDB ディスク I/O の最適化」を参照してください。

innodb_max_dirty_pages_pct

InnoDB は、ダーティーページの割合がこの値を超えないように、バッファープールからデータをフラッシュしようと試みます。

innodb_max_dirty_pages_pct 設定は、フラッシュアクティビティーのターゲットを確立します。 フラッシュの頻度には影響を与えません。 フラッシュの頻度の管理については、セクション15.8.3.5「バッファープールのフラッシュの構成」を参照してください。