このページは機械翻訳したものです。
InnoDB
構成に関する最初の決定には、データファイル、ログファイル、ページサイズおよびメモリーバッファの構成が含まれます。 InnoDB
インスタンスを作成する前に、データファイル、ログファイルおよびページサイズの構成を定義することをお薦めします。 InnoDB
インスタンスの作成後にデータファイルまたはログファイルの構成を変更するには、簡単でない手順が必要になる場合があり、ページサイズを定義できるのは、InnoDB
インスタンスが最初に初期化されたときのみです。
これらのトピックに加えて、このセクションでは、構成ファイルでの InnoDB
オプションの指定、InnoDB
初期化情報の表示、および記憶域に関する重要な考慮事項について説明します。
MySQL はデータファイル、ログファイルおよびページサイズの構成設定を使用して InnoDB
インスタンスを初期化するため、InnoDB
を初めて初期化する前に、MySQL が起動時に読み取る構成ファイルでこれらの設定を定義することをお薦めします。 InnoDB
は MySQL サーバーの起動時に初期化され、InnoDB
の最初の初期化は通常、MySQL サーバーの初回起動時に行われます。
サーバーの起動時に読み取られる任意のオプションファイルの [mysqld]
グループ内に、InnoDB
オプションを配置できます。 MySQL オプションファイルの場所は、セクション4.2.2.2「オプションファイルの使用」 で説明されています。
mysqld が特定のファイル (および mysqld-auto.cnf
) からのみオプションを読み取るようにするには、サーバーの起動時にコマンド行で最初のオプションとして --defaults-file
オプションを使用します:
mysqld --defaults-file=path_to_configuration_file
起動時に InnoDB
の初期化情報を表示するには、コマンドプロンプトから mysqld を起動します。 コマンドプロンプトから mysqld を起動すると、初期化情報がコンソールに出力されます。
たとえば、Windows では、mysqld が C:\Program Files\MySQL\MySQL Server 8.0\bin
にある場合、次のように MySQL サーバーを起動します:
C:\> "C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld" --console
Unix に似たシステムでは、mysqld は MySQL インストールの bin
ディレクトリにあります:
shell> bin/mysqld --user=mysql &
サーバー出力をコンソールに送信しない場合は、起動後にエラーログを確認して、起動プロセス中に InnoDB
によって出力された初期化情報を確認します。
他の方法を使用した MySQL の起動の詳細は、セクション2.10.5「MySQL を自動的に起動および停止する」 を参照してください。
InnoDB
では、起動時にすべてのユーザーテーブルおよび関連データファイルが開かれるわけではありません。 ただし、InnoDB
では、データディクショナリで参照されるテーブルスペースファイル (*.ibd
ファイル) の存在がチェックされます。 テーブルスペースファイルが見つからない場合、InnoDB
はエラーをログに記録し、起動順序を続行します。 redo ログで参照されるテーブルスペースファイルは、redo アプリケーションのクラッシュリカバリ中に開くことができます。
起動構成を続行する前に、次の記憶域関連の考慮事項を確認してください。
場合によっては、一部のデータが同じ物理ディスク上に配置されてない場合に、データベースのパフォーマンスが改善されることがあります。 非常に多くの場合、ログファイルをデータとは別のディスク上に配置すると、パフォーマンスの改善に役立ちます。 たとえば、システムテーブルスペースデータファイルとログファイルを異なるディスクに配置できます。
InnoDB
データファイルに RAW ディスクパーティション (RAW デバイス) を使用して、I/O を高速化することもできます。 システムテーブルスペースに対する RAW ディスクパーティションの使用を参照してください。-
InnoDB
はトランザクションセーフな (ACID に準拠した) MySQL 用のストレージエンジンであり、ユーザーデータを保護するためのコミット、ロールバック、およびクラッシュリカバリ機能を備えています。 ただし、ベースとなるオペレーティングシステムやハードウェアが公表どおりに機能しない場合は、実行できません。 多くのオペレーティングシステムやディスクサブシステムでは、パフォーマンスを改善するために書き込み操作が遅延したり、再指示されたりする可能性があります。 一部のオペレーティングシステムでは、まさにfsync()
システムコールは、ファイルのすべての未書き込みデータがフラッシュされるまで待機するべきですが、実際には、データが安定したストレージにフラッシュされる前に返される可能性があります。 このため、オペレーティングシステムのクラッシュや停電によって最近コミットされたデータが破損したり、さらに最悪の場合、書き込み操作が再指示されたためにデータベースが破損したりすることもあります。 データの完全性が重要である場合は、本番環境で何かを使用する前に、何らかの形で「電源プラグを抜く」テストを実行してください。 macOS では、InnoDB
は特別なfcntl()
ファイルフラッシュ方法を使用します。 Linux では、ライトバックキャッシュを無効にすることが推奨されています。ATA/SATA ディスクドライブ上で
hdparm -W0 /dev/hda
のようなコマンドを使用すると、ライトバックキャッシュを無効にできる場合があります。 一部のドライブやディスクコントローラでは、ライトバックキャッシュを無効にできない可能性があることに注意してください。 ユーザーを保護する
InnoDB
のリカバリ機能に関しては、InnoDB
では二重書き込みバッファーと呼ばれる構造に関連したファイルフラッシュ技術が使用されています。これは、デフォルトで有効になっています (innodb_doublewrite=ON
)。 二重書込みバッファを使用すると、予期しない終了または停電後のリカバリの安全性が向上し、fsync()
操作の必要性を減らすことで、ほとんどの Unix のパフォーマンスが向上します。 データの完全性またはエラーの可能性に関心がある場合は、innodb_doublewrite
オプションを有効のままにすることが推奨されています。 二重書き込みバッファーの追加情報については、セクション15.11.1「InnoDB ディスク I/O」を参照してください。InnoDB
で NFS を使用する前に、MySQL での NFS の使用 で概説されている潜在的な問題を確認してください。
innodb_data_file_path
の起動オプションでは、InnoDB
システムテーブルスペースデータファイルの名前、サイズおよび属性を定義します。 MySQL サーバーを初期化する前にこのオプションを構成しない場合、デフォルトの動作では、12MB を少し超える単一の自動拡張データファイルが ibdata1
という名前で作成されます:
mysql> SHOW VARIABLES LIKE 'innodb_data_file_path';
+-----------------------+------------------------+
| Variable_name | Value |
+-----------------------+------------------------+
| innodb_data_file_path | ibdata1:12M:autoextend |
+-----------------------+------------------------+
完全なデータファイル指定構文には、ファイル名、ファイルサイズ、autoextend
属性および max
属性が含まれます:
file_name:file_size[:autoextend[:max:max_file_size]]
ファイルサイズは、K
、M
または G
をサイズ値に追加することで、KB、MB または GB 単位で指定します。 データファイルのサイズを KB 単位で指定する場合は、1024 の倍数で指定します。 それ以外の場合、キロバイト値はもっとも近いメガバイト (MB) 境界に丸められます。 ファイルサイズの合計は、12MB 以上である必要があります。
セミコロンで区切られたリストを使用して、複数のデータファイルを指定できます。 例:
[mysqld]
innodb_data_file_path=ibdata1:50M;ibdata2:50M:autoextend
autoextend
および max
属性は、最後に指定されたデータファイルにのみ使用できます。
autoextend
属性が指定されている場合、データファイルのサイズは領域が必要になると 64MB ずつ自動的に増加します。 innodb_autoextend_increment
変数は増分サイズを制御します。
自動拡張データファイルの最大サイズを指定するには、autoextend
属性のあとに max
属性を使用してください。 max
属性は、ディスク使用量の制約が重要な場合にのみ使用します。 次の構成では、ibdata1
を 500MB の制限まで拡大できます:
[mysqld]
innodb_data_file_path=ibdata1:12M:autoextend:max:500M
二重書込みバッファページ用の十分な領域が確保されるように、first システムのテーブルスペースデータファイルには最小ファイルサイズが適用されます。 次のテーブルに、各 InnoDB
ページサイズの最小ファイルサイズを示します。 デフォルトの InnoDB
ページサイズは 16384 (16KB) です。
ページサイズ (innodb_page_size) | 最小ファイルサイズ |
---|---|
16384 (16KB) 以下 | 3MB |
32768 (32KB) | 6MB |
65536 (64KB) | 12MB |
ディスクがいっぱいになった場合は、別のディスクにデータファイルを追加できます。 その手順は、システムテーブルスペースのサイズ変更を参照してください。
個々のファイルのサイズ制限は、オペレーティングシステムによって決まります。 大規模ファイルをサポートするオペレーティングシステムでは、ファイルサイズを 4GB を超える値に設定できます。 データファイルとして生のディスクパーティションを使用することもできます。 システムテーブルスペースに対する RAW ディスクパーティションの使用を参照してください。
InnoDB
ではファイルシステムの最大ファイルサイズが認識されないため、最大ファイルサイズが 2G バイトのような小さい値になっているファイルシステムでは注意してください。
システムテーブルスペースファイルは、デフォルトでデータディレクトリ (datadir
) に作成されます。 別の場所を指定するには、innodb_data_home_dir
オプションを使用できます。 たとえば、myibdata
という名前のディレクトリにシステムテーブルスペースデータファイルを作成するには、次の構成を使用します:
[mysqld]
innodb_data_home_dir = /myibdata/
innodb_data_file_path=ibdata1:50M:autoextend
innodb_data_home_dir
の値を指定する場合は、末尾にスラッシュが必要です。 InnoDB
ではディレクトリが作成されないため、サーバーを起動する前に、指定したディレクトリが存在することを確認してください。 また、MySQL サーバーに、ディレクトリにファイルを作成するための適切なアクセス権があることを確認してください。
InnoDB
は、innodb_data_home_dir
の値をデータファイル名にテキストで連結することで、各データファイルのディレクトリパスを形成します。 innodb_data_home_dir
が定義されていない場合、デフォルト値は 「./」(データディレクトリ) です。 (MySQL サーバーは、実行を開始すると現在の作業ディレクトリをデータディレクトリに変更します。)
または、システムテーブルスペースデータファイルの絶対パスを指定することもできます。 次の構成は、前述の構成と同等です:
[mysqld]
innodb_data_file_path=/myibdata/ibdata1:50M:autoextend
innodb_data_file_path
の絶対パスを指定すると、設定は innodb_data_home_dir
設定と連結されません。 システムテーブルスペースファイルは、指定した絶対パスに作成されます。 サーバーを起動する前に、指定したディレクトリが存在している必要があります。
MySQL 8.0.20 の時点では、二重書込みバッファ記憶域は二重書込みファイルに存在し、二重書込みページの記憶域の場所に対する柔軟性を提供します。 以前のリリースでは、二重書込みバッファ記憶域はシステムテーブルスペースに存在していました。 innodb_doublewrite_dir
変数は、InnoDB
が起動時に二重書込みファイルを作成するディレクトリを定義します。 ディレクトリが指定されていない場合、二重書込みファイルが innodb_data_home_dir
ディレクトリに作成され、指定されていない場合はデータディレクトリにデフォルト設定されます。
二重書込みファイルを innodb_data_home_dir
ディレクトリ以外の場所に作成するには、innodb_doublewrite_dir
変数を構成します。 例:
innodb_doublewrite_dir=/path/to/doublewrite_directory
その他の二重書込みバッファ変数では、二重書込みファイルの数、スレッド当たりのページ数および二重書込みバッチサイズを定義できます。 二重書込みバッファ構成の詳細は、セクション15.6.4「二重書き込みバッファー」 を参照してください。
デフォルトでは、InnoDB
は ib_logfile0
および ib_logfile1
という名前のデータディレクトリに 2 つの 5MB redo ログファイルを作成します。
次のオプションを使用して、デフォルトの構成を変更できます:
-
innodb_log_group_home_dir
は、InnoDB
ログファイル (redo ログ) へのディレクトリパスを定義します。 このオプションが構成されていない場合、InnoDB
ログファイルは MySQL データディレクトリ (datadir
) に作成されます。このオプションを使用すると、潜在的な I/O リソースの競合を回避するために、
InnoDB
ログファイルをInnoDB
データファイルとは異なる物理記憶域の場所に配置できます。 例:[mysqld] innodb_log_group_home_dir = /dr3/iblogs
注記InnoDB
ではディレクトリが作成されないため、サーバーを起動する前にログディレクトリが存在することを確認してください。 必要なディレクトリを作成するには、Unix または DOS のmkdir
コマンドを使用します。MySQL サーバーに、ログディレクトリにファイルを作成するための適切なアクセス権があることを確認します。 より一般的に、サーバーは、ログファイルを作成する必要があるディレクトリでアクセス権を持っている必要があります。
innodb_log_files_in_group
は、ロググループ内のログファイルの数を定義します。 デフォルトおよび推奨値は 2 です。innodb_log_file_size
は、ロググループ内の各ログファイルのサイズをバイト単位で定義します。 ログファイルを結合したサイズ (innodb_log_file_size
*innodb_log_files_in_group
) は、512G バイトよりもわずかに小さい最大値を上回ることができません。 たとえば、255 GB のログファイルのペアは制限に近づいていますが、それを超えていません。 デフォルトのログファイルサイズは 48MB です。 一般に、ログファイルの合計サイズは、サーバーがワークロードアクティビティのピークおよびトラブルをスムーズにできる十分な大きさである必要があります。これは、書込みアクティビティを 1 時間以上処理するための十分な redo ログ領域があることを意味することがよくあります。 値を大きくするほど、バッファープール内で必要となるチェックポイントフラッシュアクティビティーの数が少なくなるため、ディスク I/O を節約できます。 追加情報については セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。
デフォルトでは、undo ログは、MySQL インスタンスの初期化時に作成される 2 つの undo テーブルスペースに存在します。 undo ログの I/O パターンにより、undo テーブルスペースは SSD 記憶域の適切な候補になります。
innodb_undo_directory
変数は、InnoDB
がデフォルトの undo テーブルスペースを作成するパスを定義します。 この変数が定義されていない場合、デフォルトの undo テーブルスペースがデータディレクトリに作成されます。 innodb_undo_directory
変数は動的ではありません。 構成するには、サーバーを再起動する必要があります。
追加の undo テーブルスペースの構成の詳細は、セクション15.6.3.4「undo テーブルスペース」 を参照してください。
グローバル一時テーブルスペースには、ユーザー作成一時テーブルに対する変更のロールバックセグメントが格納されます。
デフォルトでは、InnoDB
は、ibtmp1
という名前の単一の自動拡張グローバル一時テーブルスペースデータファイルを innodb_data_home_dir
ディレクトリに作成します。 初期ファイルサイズは 12MB を少し超えています。
innodb_temp_data_file_path
変数は、グローバル一時テーブルスペースデータファイルのパス、ファイル名およびファイルサイズを指定します。 ファイルサイズは、サイズ値に K、M または G を追加して KB、MB または GB で指定します。 ファイルのサイズの合計は、12MB より少し大きくする必要があります。
グローバル一時テーブルスペースデータファイルの代替の場所を指定するには、起動時に innodb_temp_data_file_path
変数を構成します。
MySQL 8.0.15 以前では、InnoDB
が内部一時テーブル (internal_tmp_disk_storage_engine=InnoDB
) のディスク上の記憶域エンジンとして構成されている場合、セッション一時テーブルスペースには、オプティマイザによって作成されたユーザー作成一時テーブルおよび内部一時テーブルが格納されます。 MySQL 8.0.16 以降では、InnoDB
ストレージエンジンは常にディスク上の内部一時テーブルに使用されます。
innodb_temp_tablespaces_dir
変数は、InnoDB
がセッション一時テーブルスペースを作成する場所を定義します。 デフォルトの場所は、データディレクトリ内の#innodb_temp
ディレクトリです。
セッション一時テーブルスペースに別の場所を指定するには、起動時に innodb_temp_tablespaces_dir
変数を構成します。 データディレクトリに対する完全修飾パスまたは相対パスが許可されます。
innodb_page_size
オプションでは、MySQL インスタンス内のすべての InnoDB
テーブルスペースのページサイズを指定します。 この値は、インスタンスの作成時に設定され、その後は一定のままです。 有効な値は、64KB、32KB、16KB (デフォルト)、8KB および 4KB です。 または、ページサイズをバイト単位で指定できます (65536、32768、16384、8192、4096)。
16KB のデフォルトページサイズは、広範囲のワークロードに適しています。特に、バルク更新を伴うテーブルスキャンおよび DML 操作を含むクエリーに適しています。 ページサイズが小さいほど、多くの小規模な書き込みを伴う OLTP ワークロードの効率性が高くなる可能性があります。その一方で、単一のページに数多くの行が含まれる場合は、競合の問題が発生する可能性もあります。 ページを小さくすると、一般に小さなブロックサイズが使用される SSD ストレージデバイスの効率性が高くなる可能性もあります。 InnoDB
のページサイズをストレージデバイスのブロックサイズに近づけると、ディスクに再度書き込まれる未変更データの量が最小限になります。
MySQL は、様々なキャッシュおよびバッファにメモリーを割り当てて、データベース操作のパフォーマンスを向上させます。 InnoDB
にメモリーを割り当てる場合は、常にオペレーティングシステムに必要なメモリー、他のアプリケーションに割り当てられたメモリー、および他の MySQL バッファとキャッシュに割り当てられたメモリーを考慮してください。 たとえば、MyISAM
テーブルを使用する場合は、キーバッファ (key_buffer_size
) に割り当てられるメモリー量を考慮してください。 MySQL バッファおよびキャッシュの概要は、セクション8.12.3.1「MySQL のメモリーの使用方法」 を参照してください。
InnoDB
に固有のバッファは、次のパラメータを使用して構成されます:
-
innodb_buffer_pool_size
は、バッファプールのサイズを定義します。バッファプールは、InnoDB
テーブル、インデックスおよびその他の補助バッファのキャッシュデータを保持するメモリー領域です。 バッファプールのサイズはシステムパフォーマンスにとって重要であり、通常、innodb_buffer_pool_size
はシステムメモリーの 50 から 75% に構成することをお薦めします。 デフォルトのバッファープールサイズは 128MB です。 その他のガイダンスは、セクション8.12.3.1「MySQL のメモリーの使用方法」 を参照してください。InnoDB
バッファープールサイズを構成する方法については、セクション15.8.3.1「InnoDB バッファプールサイズの構成」 を参照してください。 バッファープールサイズは、起動時または動的に構成できます。メモリーが大量にあるシステムでは、バッファプールを複数のバッファプールインスタンスに分割することで同時実行性を向上させることができます。 バッファープールインスタンスの数は、
innodb_buffer_pool_instances
オプションによって制御されます。 デフォルトでは、InnoDB
はバッファプールインスタンスを 1 つ作成します。 バッファープールインスタンスの数は起動時に構成できます。 詳細は、セクション15.8.3.2「複数のバッファープールインスタンスの構成」を参照してください。 innodb_log_buffer_size
は、InnoDB
がディスク上のログファイルへの書込みに使用するバッファのサイズをバイト単位で定義します。 デフォルトのサイズは 16M バイトです。 ログバッファーを大きくすると、トランザクションがコミットする前にディスクにログを書き込まなくても、大規模なトランザクションを実行できます。 多数の行を更新、挿入または削除するトランザクションがある場合は、ログバッファのサイズを増やしてディスク I/O を節約することを検討してください。innodb_log_buffer_size
は起動時に構成できます。 関連情報については、セクション8.5.4「InnoDB redo ロギングの最適化」を参照してください。
32 ビット版の GNU/Linux x86 では、高すぎるメモリー使用率を設定しないように注意してください。glibc
では、プロセスヒープがスレッドスタック上で増加することが許可されている可能性があるため、サーバーがクラッシュします。 グローバルおよびスレッドごとのバッファおよびキャッシュ用に mysqld プロセスに割り当てられたメモリーが 2GB に近いか、それを超えるとリスクがあります。
MySQL のグローバルおよびスレッドごとのメモリー割当てを計算する次のような式を使用して、MySQL メモリー使用量を見積もることができます。 MySQL のバージョンおよび構成でバッファおよびキャッシュを考慮するように式を変更する必要がある場合があります。 MySQL バッファおよびキャッシュの概要は、セクション8.12.3.1「MySQL のメモリーの使用方法」 を参照してください。
innodb_buffer_pool_size
+ key_buffer_size
+ max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size)
+ max_connections*2MB
各スレッドではスタックが使用され (多くの場合は 2M バイトですが、Oracle Corporation が提供する MySQL バイナリでは 256K バイトだけです)、最悪のケースでは、sort_buffer_size + read_buffer_size
の追加メモリーも使用されます。
Linux では、カーネルでラージページサポートが有効になっている場合、InnoDB
はラージページを使用してバッファプールにメモリーを割り当てることができます。 セクション8.12.3.2「ラージページのサポートの有効化」を参照してください。