--ignore-builtin-innodb

このオプションを指定すると、サーバーの動作が、まるで組み込み InnoDB が存在していないかのようになります。これを指定すると、ほかの InnoDB オプションが認識されなくなります。このオプションは MySQL 5.1.33.で追加されました。

--innodb[=value]

サーバーが InnoDB サポートでコンパイルされた場合に、InnoDB ストレージエンジンの読み込みを制御します。MySQL 5.1.36 以降、このオプションは 3 つの状態を取る形式となっており、OFF、ON、FORCE のいずれかの値を指定できます。MySQL 5.1.36 より前では、これはブール型のオプションです。InnoDB を有効にするには --innodb を、無効にするには --skip-innodb を、それぞれ使用します。Server Options for Loading Plugins を参照してください。

--innodb_status_file

InnoDB が MySQL のデータディレクトリ内に innodb_status.<pid> という名前のファイルを作成するかどうかを制御します。有効にすると、InnoDB は定期的に SHOWENGINEINNODBSTATUS の出力をこのファイルに書き込みます。

このファイルはデフォルトでは作成されません。これを作成するには、mysqld の起動時に --innodb_status_file=1 オプションを指定します。このファイルは、通常のシャットダウン中に削除されます。

ignore_builtin_innodb

サーバー起動時に --ignore-builtin-innodb オプションが指定されたかどうか。このオプションが指定されると、サーバーの動作が、まるで組み込み InnoDB が存在していないかのようになります。(MySQL 5.1.33 からの導入)

innodb_adaptive_hash_index

InnoDB の適応型ハッシュインデックスを有効、無効のいずれにするか (項9.10.4. 「適応型ハッシュインデックス」を参照)。この変数はデフォルトで有効にされています。これを無効にするには、サーバー起動時に --skip-innodb_adaptive_hash_index を指定します。(MySQL 5.1.24 からの導入)

innodb_additional_mem_pool_size

InnoDB がデータ辞書情報と別の内部データ構造を格納するために利用する、メモリープールのバイトでのサイズです。より多くのテーブルをアプリケーション内に持っていると、ここに割り当てるためにより多くのメモリーが必要になります。もし InnoDB がこのプール内のメモリーを使い果たしてしまったら、これは OS からメモリーを割り当て始め、MySQL エラーログに警告メッセージを書きます。デフォルトの値は 1M バイトです。

innodb_autoextend_increment

自動拡大テーブル領域ファイルがいっぱいになったときにサイズを拡大するためのインクリメントサイズ (M バイト)。デフォルト値は 8 です。

innodb_buffer_pool_awe_mem_mb

AWE メモリー内に置かれたときの、バッファープールのサイズ (M バイト)。もしこれが 0 以上なら、innodb_buffer_pool_size は InnoDB がその AWE メモリーをマップする mysqld の 32 ビットアドレス領域内のウィンドウです。innodb_buffer_pool_size の適正な値は 500M バイトです。指定可能な最大値は、63000 です。

AWE メモリーを活用するには、自分で MySQL をリコンパイルする必要があります。これを行うのに必要な現在のプロジェクト設定は、storage/innobase/os/os0proc.c ソースファイル内で見つけることができます。

この変数は MySQL 5.1.13 で削除されました。それより前では、これは 32 ビット Windows でしか意味を持ちません。もしお使いの 32 ビット Windows OS が 4G バイト以上のメモリーをサポートするなら、いわゆる 「Address Windowing Extensions,」 を利用することで、この変数を利用して InnoDB バッファープールを AWE 物理的メモリーに割り当てることができます。

innodb_autoinc_lock_mode

自動インクリメント値の生成に使用するロックモード。許可される値は 0、1、2 で、それぞれ 「従来」、「連続」、「インターリーブ」 の各ロックモードに対応しています。これらのモードの特徴については、項9.4.3. 「InnoDB の AUTO_INCREMENT 処理」 を参照してください。

この変数は、MySQL 5.1.22 でデフォルト値 1 (「連続」 ロックモード) として追加されました。5.1.22 より前では、InnoDB は 「従来」 ロックモードを使用します。

innodb_buffer_pool_size

InnoDB がそのテーブルのデータとインデックスをキャッシュするために利用する、メモリーバッファーのバイトでのサイズです。デフォルトの値は 8M バイトです。この値を大きく設定するほど、テーブル内のデータにアクセスするのに必要なディスク I/O は少なくなります。専用のデータベースサーバー上で、これをマシンの物理的メモリーサイズの最大 80% に設定すると良いでしょう。しかし、物理的メモリーの競合が OS 内でページングを引き起こす可能性があるので、あまり大きく設定しないでください。

innodb_checksums

InnoDB は、壊れたハードウェアやデータファイルに対する追加フォールトトレランスを保証するディスクからのすべてのページの読み込み上で、チェックサムの妥当性確認を利用することができます。この妥当性確認はデフォルトで有効にされています。しかし、まれに (ベンチマークが起動している時等)、この追加安全機能は必要なく、--skip-innodb-checksums を利用して無効にすることができます。

innodb_commit_concurrency

同時にコミットすることができるスレッドの数。値 0 (デフォルト) を指定した場合、任意の数のトランザクションが同時にコミットできます。

MySQL 5.1.36 以降では、実行時に innodb_commit_concurrency の値をゼロからゼロ以外の値に変更したりその逆を行ったりすることはできません。値をゼロ以外のある値から別の値に変更することは可能です。

innodb_concurrency_tickets

InnoDB に同時に入ることができるスレッドの数は、innodb_thread_concurrency 変数によって決められます。スレッドが InnoDB に入ろうとするときにもし並行処理の限度までスレッド数が達していたら、それらは列になります。スレッドが InnoDB に入るのを許可されると、innodb_concurrency_tickets の値と同等の 「フリーチケット」 をたくさん与えられ、スレッドはそのチケットを使ってしまうまでは自由に InnoDB に出入りできます。それ以降は、スレッドが次に InnoDB に入ろうとしたときに、再度並行処理確認の対象となります。(または列に並ぶ可能性もある)デフォルト値は 500 です。

innodb_data_file_path

独立したデータファイルとそれらのサイズへのパス。各データファイルへの完全ディレクトリパスは、ここに指定された各パスへの innodb_data_home_dir を結合することによって形作られます。ファイルサイズは、サイズ値に K、M、または G を付加して、K バイト、M バイト、または G バイト (1024M バイト) で指定されます。ファイルサイズの合計は最低 10M バイト必要です。もし innodb_data_file_path を指定しなければ、デフォルト動作で ibdata1 と名づけられた 10M バイトの単一自動拡大データファイルが作成されます。各ファイルのサイズ制限は OS によって決定されます。大きいファイルをサポートする OS のサイズを 4G バイト以上に設定することができます。raw ディスクパーティションをデータファイルとして利用することもできます。InnoDB のテーブル領域ファイルを設定する方法の詳細については、項9.2. 「InnoDB 設定」 を参照してください。

innodb_data_home_dir

共有テーブル領域に含まれるすべての InnoDB データファイルのディレクトリパスの共通部分。innodb_file_per_table が有効な場合、この設定はファイル単位テーブル領域の場所には影響を与えません。デフォルト値は、MySQL のデータディレクトリです。値を空の文字列として指定した場合には、innodb_data_file_path 内で完全なファイルパスを使用することができます。

innodb_doublewrite

この変数が有効 (デフォルト) な場合、InnoDB はすべてのデータを 2 回格納します。1 回目は二重書き込みバッファーに、そして次に実際のデータファイルに格納します。この変数は、データの整合性や起こり得る失敗に対する心配よりも、ベンチマークや最高性能が要求されるときに、--skip-innodb_doublewrite を利用して止めることができます。

innodb_fast_shutdown

InnoDB のシャットダウンモード。デフォルトの値は 1 で、その場合には 「高速」 シャットダウン (通常タイプのシャットダウン) が実行されます。値が 0 の場合、InnoDB は完全な消去と挿入バッファーのマージを行ってから、シャットダウンを行います。これらの操作には数分間、または極端な場合には数時間かかることがあります。値が 1 の場合、InnoDB はシャットダウン時にこれらの処理をスキップします。値が 2 の場合、InnoDB はそのログをフラッシュし、まるで MySQL がクラッシュしたかのように急にシャットダウンします。コミットされたトランザクションはなくなりませんが、次の起動の際にクラッシュ復旧が行われます。2 の値は NetWare 上では利用できません。

innodb_file_io_threads

InnoDB 内のファイル I/O スレッド数。通常、これはデフォルト値である 4 のままにしておくべきですが、Windows 上のディスク I/O にとってはそれよりも大きい値の方がよいかもしれません。Unix 上では、数値を増やしても効果はありません。InnoDB は必ずデフォルト値を利用します。

innodb_file_per_table

innodb_file_per_table が無効 (デフォルト) な場合、InnoDB は共有テーブル領域にテーブルを作成します。innodb_file_per_table を有効にすると、InnoDB はデータとインデックスを共有テーブル領域に格納するのではなく、それ自体の .ibd ファイルを利用してそれぞれの新しいテーブルを作成し、そこに格納します。項9.2.1. 「Per-Table テーブル領域を利用する」 を参照してください。

innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit が 0 の場合、ログバッファーは 1 秒に 1 回ログファイルに書き込まれ、ディスク操作へのフラッシュはログファイル上で行われますが、トランザクションコミットの際には何も行われません。値が 1 (デフォルト) のときは、ログファイルは各トランザクションコミットのときにログファイルに書き込まれ、ディスク操作へのフラッシュはログファイル上で行われます。値が 2 の場合、ログバッファーはコミットごとにファイルに書き込まれますが、ディスク操作へのフラッシュはそこでは行われません。しかし、値が 2 のときもログファイル上でのフラッシュは 1 秒に 1 回行われます。1 秒に 1 回のフラッシュは、処理スケジュールの発行のため 100% 保証されたものではないということに注意してください。

デフォルト値の 1 が、ACID に準拠するために必要な値です。より良い性能のために 1 以外の値を設定することもできますが、その場合 1 つのクラッシュの中で最大 1 秒分のトランザクションを失う可能性があります。値が 0 の場合、mysqld プロセスがクラッシュするたびに、直前の 1 秒間のトランザクションが消去される可能性があります。値が 2 の場合、オペレーティングシステムがクラッシュした場合と停電が発生した場合にのみ、直前の 1 秒間のトランザクションが消去される可能性があります。しかし、InnoDB のクラッシュ復旧は影響を受けないので、値に関係なくクラッシュ復旧は行われます。

InnoDB とトランザクションを共に利用してレプリケーション設定で最大の耐久力と一貫性を得るには、お使いのマスタサーバー my.cnf 内で innodb_flush_log_at_trx_commit = 1 および sync_binlog = 1 を使用してください。

innodb_flush_method

デフォルトでは、InnoDB は fsync() を使ってデータとログファイルの両方のフラッシュを行います。innodb_flush_method オプションが O_DSYNC に設定されると、InnoDB はログファイルをオープン、フラッシュするために O_SYNC を使用し、データファイルをフラッシュするために fsync() を使用します。(一部の GNU/Linux バージョン、FreeBSD、および Solaris で利用可能な) O_DIRECT が指定されると、InnoDB はデータファイルをオープンするために O_DIRECT (Solaris では directio()) を利用し、データとログファイルの両方をフラッシュするために fsync() を利用します。InnoDB は fdatasync() の代わりに fsync() を利用すること、また様々な種類の Unix 上で問題があったため、デフォルトで O_DSYNC は利用しないということに注意してください。この変数は Unix に対してだけ関連があります。Windows 上では、フラッシュの方法は毎回 async_unbuffered で、変更することはできません。

この変数の異なる値は InnoDB のパフォーマンスに著しい影響を持ちます。たとえば、InnoDB データとログファイルが SAN 上に位置するいくつかのシステム上では、innodb_flush_method を O_DIRECT に設定することは、3 つの要因によってシンプルな SELECT ステートメントの性能を劣らせる可能性があるということが発見されました。

以前は、デフォルト動作を実現するために値 fdatasync を指定できました。MySQL 5.1.24 以降ではそれが不可能になりました。というのも、値 fdatasync を指定した場合に fdatasync() ではなく fsync() を使ってフラッシュが行われるのは、混乱を招く可能性があるからです。

innodb_force_recovery

クラッシュ復旧モード。指定可能な値は 0 から 6 までです。これらの値の意味については、項9.6.2. 「InnoDB 復旧の強制」 を参照してください。

innodb_lock_wait_timeout

InnoDB のトランザクションが行ロックの取得をあきらめるまでに待機するタイムアウト秒数。デフォルトは 50 秒。ある InnoDB トランザクションによってロックされている行へのアクセスを試みる別のトランザクションは、この秒数だけ最大待ったあと、次のエラーを発行します。

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

ロック待ちタイムアウトが発生すると、現在のステートメントは実行されません。現在のトランザクションはロールバックされません。(トランザクション全体をロールバックさせるには、MySQL 5.1.15 以降で利用可能な --innodb_rollback_on_timeout オプションを指定してサーバーを起動する。項9.12. 「InnoDB エラー処理」も参照。)

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

InnoDB は、自身のロックテーブルのトランザクションデッドロックを即座に検出し、トランザクションを 1 つロールバックします。ロック待ちタイムアウト値はそのような待機には適用されません。

innodb_locks_unsafe_for_binlog

この変数は、InnoDB がギャップロックを使って検索やインデックス走査を行う方法に影響を与えます。InnoDB では通常、インデックス行ロックとギャップロックを組み合わせた「ネクストキーロック」と呼ばれるアルゴリズムが使用されます。InnoDB は、それがテーブルインデックスを検索や走査するときに、遭遇したインデックスレコード上で共有または排他ロックを設定する、という方法で行レベルロックを実行します。従って、行レベルロックは実際はインデックスレコードロックであるということになります。さらに、あるインデックスレコードに対するネクストキーロックは、そのインデックスレコードの前の 「ギャップ」 にも影響を与えます。つまり、ネクストキーロックは、インデックスレコードロックと、そのインデックスレコードの前のギャップに対するギャップロックとを組み合わせたものです。あるセッションがインデックス内のレコード R 上に共有または排他ロックを持っている場合、別のセッションがインデックスの順番で R の直前にあたるギャップに新しいインデックスレコードを挿入することはできません。項9.8.4. 「InnoDB レコード、ギャップ、およびネクストキーロック」 を参照してください。

innodb_locks_unsafe_for_binlog の値はデフォルトで 0 (無効) になっていますが、これは、ギャップロックが有効であることを意味します。InnoDB はネクストキーロックを使って検索やインデックス走査を行います。この変数を有効にするには、値を 1 に設定します。そうするとギャップロックが無効になります。InnoDB はインデックスレコードロックのみを使って検索やインデックス走査を行います。

innodb_locks_unsafe_for_binlog を有効にしても、外部キー制約チェックや重複キー確認でのギャップロック使用は無効になりません。

innodb_locks_unsafe_for_binlog を有効にした場合の影響は、トランザクション遮断レベルを READ COMMITTED に設定した場合の影響に似ていますが、同じではありません。

したがって、READ COMMITTED は innodb_locks_unsafe_for_binlog よりも細かく柔軟な制御を提供すると言えます。ギャップロックに対する遮断レベルの影響に関する追加の詳細については、項8.4.6. 「SET TRANSACTION 構文」 を参照してください。

innodb_locks_unsafe_for_binlog を有効にするとファントムの問題が発生する可能性があります。なぜなら、ギャップロックが無効だとほかのセッションが新しい行をギャップに挿入できるからです。child テーブルの id カラム上にインデックスが設定された状態で、次のように識別子の値が 100 より大きいすべての行をテーブルから読み取り、その選択された行の特定のカラムをあとで更新できるようにそれらの行をロックするものとします。

SELECT * FROM child WHERE id > 100 FOR UPDATE;

クエリーは、id が 100 より大きい最初のレコードからインデックスを走査します。その範囲内のインデックスレコード上に設定されたロックがギャップへの挿入を禁止しなければ、別のセッションがそのテーブルに新しい行を挿入することができます。したがって、同じトランザクション内で同じ SELECT を再度実行すると、クエリーから返された結果セット内に新しい行を見つけることができます。これは、もしデータベースに新しい項目が追加されると、InnoDB はシリアリザビリティを保証しないということも意味します。したがって、innodb_locks_unsafe_for_binlog が有効な場合に InnoDB によって保証される最大の遮断レベルは、READ COMMITTED になります。(コンフリクトシリアリザビリティは保証されたままです)。ファントムの追加情報については、項9.8.5. 「ネクストキーロックによるファントム問題の回避」 を参照してください。

innodb_locks_unsafe_for_binlog を有効にした場合には、次のような影響も発生します。

このテーブルから始まる、次の例を検討してみてください:

CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB;
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;

この場合はテーブルにインデックスが設定されていないので、検索やインデックス走査では、隠しクラスタインデックスを使ってレコードのロックが行われます (項9.10.1. 「クラスタインデックスと二次インデックス」を参照)。

あるクライアントが次のステートメントを使って UPDATE を実行するとします。

SET autocommit = 0;
UPDATE t SET b = 5 WHERE b = 3;

別のクライアントが最初のクライアントの実行後に次のステートメントを実行することで、UPDATE を実行するものとします。

SET autocommit = 0;
UPDATE t SET b = 4 WHERE b = 2;

InnoDB は各 UPDATE を実行する際に、まず各行の排他ロックを取得し、次にその行を変更するかどうかを判定します。InnoDB がその行を変更せず、かつ innodb_locks_unsafe_for_binlog が有効な場合には、そのロックが解放されます。それ以外の場合、トランザクションが終了するまで InnoDB はそのロックを保持します。これは、トランザクション処理に次のような影響を及ぼします。

innodb_locks_unsafe_for_binlog が無効な場合は次のように、最初の UPDATE は X ロックを取得し、それらを一切解放しません。

x-lock(1,2); retain x-lock
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); retain x-lock
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); retain x-lock

次のように、2 番目の UPDATE は (最初の更新がすべての行のロックを保持しているので) どのロックを取得しようとしてもすぐにブロックしてしまい、最初の UPDATE がコミットかロールバックを実行するまで処理を進めることができません。

x-lock(1,2); block and wait for first UPDATE to commit or roll back

innodb_locks_unsafe_for_binlog が有効な場合は次のように、最初の UPDATE は X ロックを取得したあと、変更しない行のロックは解放します。

x-lock(1,2); unlock(1,2)
x-lock(2,3); update(2,3) to (2,5); retain x-lock
x-lock(3,2); unlock(3,2)
x-lock(4,3); update(4,3) to (4,5); retain x-lock
x-lock(5,2); unlock(5,2)

2 番目の UPDATE では次のように、InnoDB は 「半一貫性」 読み取りを行い、最後にコミットされたバージョンを MySQL に返すため、MySQL はその行が UPDATE の WHERE 条件にマッチするかどうかを判定することができます。

x-lock(1,2); update(1,2) to (1,4); retain x-lock
x-lock(2,3); unlock(2,3)
x-lock(3,2); update(3,2) to (3,4); retain x-lock
x-lock(4,3); unlock(4,3)
x-lock(5,2); update(5,2) to (5,4); retain x-lock

半一貫性読み取りが利用できるのは MySQL 5.1.5 以降です。5.1.5 より前では、2 番目の UPDATE は、途中まで処理が進んだところでブロックしてしまいます。これは X ロックの取得を開始しますが、最初の UPDATE によってまだロックされている行のロックを取得しようとした時点でブロックします。次のように、2 番目の UPDATE は最初の UPDATE がコミットかロールバックを実行するまで処理を進めることができません。

x-lock(1,2); update(1,2) to (1,4); retain x-lock
x-lock(2,3); block and wait for first UPDATE to commit or roll back

この場合、2 番目の UPDATE は、影響を与える行が異なっているにもかかわらず、最初の UPDATE がコミットかロールバックを実行するまで待つ必要があります。最初の UPDATE は行 (2,3) の排他ロックを保持しており、まだ解放していません。2 番目の UPDATE は行の走査時にその同じ行の排他ロックを取得しようとしますが、取得することができません。したがって、MySQL 5.1.5 より前では、innodb_locks_unsafe_for_binlog を有効にしたとしても、UPDATE などの操作をほかの類似操作 (別の UPDATE など) のあとから実行して先に終了させることは、たとえ両者が影響を及ぼす行が異なっていても不可能です。

innodb_log_arch_dir

この変数は推奨されないため、MySQL 5.1.21 で削除されました。

innodb_log_archive

この変数は推奨されないため、MySQL 5.1.18 で削除されました。

innodb_log_buffer_size

InnoDB がディスク上のログファイルに書き込むために利用するバッファーのバイトでのサイズ。デフォルトの値は 1M バイトです。実用的な値の範囲は 1M バイトから 8M バイトです。大きいログバッファーは、トランザクションコミットの前にディスクにログを書き込む必要なく、大きいトランザクションが起動することを許容します。従って、もし大きいトランザクションを持っていたら、ログファイルを大きくしておくことでディスク I/O を節約することができます。

innodb_log_file_size

ロググループ内のそれぞれの長いファイルのバイトでのサイズ。結合したログファイルのサイズは 4G バイト未満でなければいけません。デフォルトの値は 5M バイトです。実用的な値は、N がグループ内のログファイル数だとして、バッファープールのサイズの 1M バイトから 1/N-th です。この値が大きいほどバッファープールで必要となるチェックポイントフラッシュアクティビティーが少なくなり、ディスク入出力の低減を図れます。ただし、ログファイルが大きくなるということは、クラッシュ時の復旧時間が長くなることも意味します。

innodb_log_files_in_group

ロググループ内のログファイル数。InnoDB はファイルに輪状に書き込みをします。デフォルト (そして推奨) の値は 2 です。

innodb_log_group_home_dir

InnoDB ログファイルへのディレクトリパス。もし InnoDB ログ変数を何も指定しなければ、デフォルトで MySQL データディレクトリ内に ib_logfile0 と ib_logfile1 という名前の 2 つの 5M バイトファイルを作成します。

innodb_max_dirty_pages_pct

これは 0 から 100 の範囲の間の整数です。デフォルト値は 90 です。InnoDB 内の主スレッドは、ダーティ (まだ書き込まれていない) ページの割合がこの値を超えないようにバッファープールからページを書くように試みます。

innodb_max_purge_lag

この変数は、消去操作が遅れているときに (を参照) INSERT、UPDATE、および DELETE項9.9. 「InnoDB マルチバージョン管理」 操作をどのように遅らせるかをコントロールします。デフォルト値は 0 (遅延なし) です。

InnoDB トランザクションシステムは UPDATE か DELETE 操作によって削除マークが付けられたインデックスレコードを持つトランザクションのリストを保持します。このリストの長さを purge_lag にしてください。purge_lag が innodb_max_purge_lag を上回るとき、各 INSERT、UPDATE、および DELETE 操作は ((purge_lag/innodb_max_purge_lag)×10)–5 ミリ秒遅れます。遅れは消去バッチの最初に、10 秒ごとに計算されます。もし消去される行をを知ることができる、古い一貫性読み取りビューのために消去が起動しなかったら、その操作は遅れません。

作業負荷が不明な場合の典型的な設定は、トランザクションが小規模でサイズが 100 バイトしかなく、未消去の InnoDB テーブル行が 100M バイト存在していても問題ないと仮定すれば、100 万です。

innodb_mirrored_log_groups

データベースのために残すロググループの同一コピー数。これは 1 に設定すべきです。

innodb_open_files

この変数は InnoDB 内で複数のテーブル領域を利用する場合のみ関連があります。それは InnoDB が同時にオープンしておける .ibd ファイルの最大数を指定します。最小値は 10 です。デフォルト値は 300 です。

.ibd ファイルに利用されるファイル記述子は、InnoDB に対してのもののみです。それらは、--open-files-limit サーバーオプションによって指定されたものからは独立していて、テーブルキャッシュの操作に影響を与えません。

innodb_rollback_on_timeout

MySQL 5.1 で、InnoDB はトランザクションのタイムアウト時に最後のステートメントだけをロールバックします。--innodb_rollback_on_timeout を指定すると、トランザクションタイムアウトは InnoDB がトランザクション全体を異常終了してロールバックするよう働きかけます (MySQL 4.1 と同じ動作)。この変数は、MySQL 5.1.15 で追加されました。

innodb_stats_on_metadata

この変数が有効 (この変数が作成される前からのデフォルト) な場合、SHOW TABLE STATUS や SHOW INDEX などのメタデータステートメントの実行時や、INFORMATION_SCHEMA テーブル TABLES または STATISTICS へのアクセス時に、InnoDB は統計情報を更新します。(これらの更新は、ANALYZE TABLE で行われるものに似ている。) 無効な場合、InnoDB はそれらの処理中に統計情報を更新しません。この変数を無効にすると、テーブルやインデックスを多数含むスキーマへのアクセス速度が改善される可能性があります。またその場合、InnoDB テーブルが関係するクエリーの実行計画の安定性も高まる可能性があります。

(MySQL 5.1.17 からの導入)

innodb_support_xa

この変数が有効 (デフォルト) の場合、XA トランザクションの 2 段階コミットの InnoDB サポートが有効となり、トランザクションの準備時に追加のフラッシュが発生するようになります。

XA トランザクションを使用しない場合はこの変数を無効にすることができますが、そうした場合にはディスクフラッシュの回数が減り、InnoDB のパフォーマンスが向上します。

innodb_sync_spin_loops

スレッドが、サスペンドされる前に InnoDB 相互排他ロックが開放されるのを待つ回数。デフォルト値は 20 です。

innodb_table_locks

autocommit = 0 の場合、InnoDB は LOCK TABLES の要求を受け入れます。MySQL はすべてのスレッドがテーブルに対するすべてのロックを解放するまで、LOCK TABLES ... WRITE から戻りません。innodb_table_locks のデフォルト値は 1 です。それはもし autocommit = 0 なら LOCK TABLES は InnoDB がテーブルを内部的にロックするよう働きかけることを意味します。

innodb_thread_concurrency

InnoDB は、この変数から与えられた制限よりも少ない、またはそれと同等の制限の InnoDB 内部に多くの OS スレッドを一斉に保存しようと試みます。スレッド数がこの制限に達すると、それ以上のスレッドは、実行用の FIFO キュー内で待機状態に置かれます。ロック待ちのスレッドは、同時実行スレッド数としてカウントされません。

この変数の適切な値は環境や作業負荷によって異なります。使用するアプリケーションに適した値を決定するには、さまざまな値を試してみる必要があります。推奨値は、CPU 数の 2 倍にディスク数を加えたものです。

この変数の範囲は 0 から 1000 です。MySQL 5.1.12 より前では、20 以上の値は無限の並列性と解釈されます。5.1.12 以降では、値を 0 に設定すればスレッド並列性確認を無効にすることができます。スレッド並列性確認を無効にすると、InnoDB はスレッドを必要なだけ作成できるようになります。

MySQL 5.1.11 以前はデフォルト値は 20 で、5.1.11 以降は 8 となっています。

innodb_thread_sleep_delay

InnoDB スレッドは InnoDB の列に加わるまでに、マイクロ秒で何秒間スリープ状態にあるか。デフォルト値は 10,000 です。0 の値ではスリープ状態にはなりません。

innodb_use_legacy_cardinality_algorithm

InnoDB は、インデックスのカーディナリティーを計算するためのインデックスへのダイブを生成する際に、乱数を使用します。ところが、特定の条件下でアルゴリズムが乱数を生成しないため、ANALYZE TABLE がカーディナリティーの概算値を正しく更新しないことがあります。より優れたランダム化特性を備えた代替アルゴリズムと、使用するアルゴリズムを選択するシステム変数 innodb_use_legacy_cardinality_algorithm が、MySQL 5.1.35 で導入されました。この変数のデフォルト値は 1 (ON) で、その場合には既存アプリケーションとの互換性を維持するために元のアルゴリズムが使用されます。この変数を 0 (OFF) に設定すると、ランダム特性が改善された新しいアルゴリズムを使用できます。

5.4 では改良版のアルゴリズムがデフォルトで使用されるため、この変数は使用されません。

sync_binlog

この値が 0 より大きい場合、MySQL サーバーはバイナリログへの書き込みが sync_binlog 回発生するたびに、(fdatasync() を使用して) バイナリログとディスクとの同期を行います。バイナリログへの書き込みは、自動コミットが有効な場合はステータスごとに 1 回ずつ、それ以外の場合はトランザクションごとに 1 回ずつ発生します。sync_binlog のデフォルト値は 0 で、これは、ディスクへの同期が行われないことを示します。値を 1 にすると、もっとも安全な設定となる。これはクラッシュした場合などに失うものが、1 ステートメントあるいは 1 トランザクションに留まるためである。しかし、これはパフォーマンスを遅くするため、対応策としては、同期を高速化するために、バッテリバックアップ式キャッシュをディクスに持たせるなどする。