このページは機械翻訳したものです。
file-per-table テーブルスペースには、単一の InnoDB
テーブルのデータとインデックスが含まれ、ファイルシステム上の独自のデータファイルに格納されます。
File-per-table テーブルスペースの特性については、このセクションの次のトピックで説明します:
InnoDB
は、デフォルトで file-per-table テーブルスペースにテーブルを作成します。 この動作は、innodb_file_per_table
変数によって制御されます。 innodb_file_per_table
を無効にすると、InnoDB
によってシステムテーブルスペースにテーブルが作成されます。
innodb_file_per_table
設定は、オプションファイルで指定するか、SET GLOBAL
ステートメントを使用して実行時に構成できます。 実行時に設定を変更するには、グローバルシステム変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。
オプションファイル:
[mysqld]
innodb_file_per_table=ON
実行時の SET GLOBAL
の使用:
mysql> SET GLOBAL innodb_file_per_table=ON;
file-per-table テーブルスペースは、MySQL データディレクトリの下のスキーマディレクトリにある .idb
データファイルに作成されます。 .ibd
ファイルには、テーブル (
) の名前が付けられます。 たとえば、テーブル table_name
.ibdtest.t1
のデータファイルは、MySQL データディレクトリの下の test
ディレクトリに作成されます:
mysql> USE test;
mysql> CREATE TABLE t1 (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100)
) ENGINE = InnoDB;
shell> cd /path/to/mysql/data/test
shell> ls
t1.ibd
CREATE TABLE
ステートメントの DATA DIRECTORY
句を使用して、データディレクトリ外にファイルごとのテーブルスペースデータファイルを暗黙的に作成できます。 詳細は、セクション15.6.1.2「外部でのテーブルの作成」を参照してください。
File-per-table テーブルスペースには、システムテーブルスペースや一般テーブルスペースなどの共有テーブルスペースに比べて次の利点があります。
file-per-table テーブルスペースで作成されたテーブルを切り捨てるか削除すると、ディスク領域がオペレーティングシステムに戻されます。 共有テーブルスペースに格納されているテーブルを切り捨てるか削除すると、共有テーブルスペースデータファイル内に空き領域が作成され、これは
InnoDB
データにのみ使用できます。 つまり、テーブルの切捨てまたは削除後、共有テーブルスペースデータファイルのサイズは縮小されません。共有テーブルスペースに存在するテーブルに対するテーブルコピー
ALTER TABLE
操作では、テーブルスペースが占有するディスク領域の量を増やすことができます。 このような操作には、テーブル内のデータとインデックスの追加領域が必要になる場合があります。 この領域は file-per-table テーブルスペース用であるため、オペレーティングシステムに解放されません。file-per-table テーブルスペースに存在するテーブルで実行すると、
TRUNCATE TABLE
のパフォーマンスが向上します。File-per-table テーブルスペースデータファイルは、I/O の最適化、領域管理またはバックアップのために、別々のストレージデバイスに作成できます。 セクション15.6.1.2「外部でのテーブルの作成」を参照してください。
file-per-table テーブルスペースに存在するテーブルを別の MySQL インスタンスからインポートできます。 セクション15.6.1.3「InnoDB テーブルのインポート」を参照してください。
file-per-table テーブルスペースで作成されたテーブルは、システムテーブルスペースでサポートされていない
DYNAMIC
およびCOMPRESSED
の行フォーマットに関連付けられた機能をサポートします。 セクション15.10「InnoDB の行フォーマット」を参照してください。個々のテーブルスペースデータファイルに格納されたテーブルでは、データ破損が発生した場合、バックアップまたはバイナリログが使用できない場合、または MySQL サーバーインスタンスを再起動できない場合に、時間を節約し、リカバリが成功する可能性を向上させることができます。
MySQL Enterprise Backup を使用すると、他の
InnoDB
テーブルの使用を中断することなく、file-per-table テーブルスペースに作成されたテーブルを迅速にバックアップまたはリストアできます。 これは、様々なバックアップスケジュールに関するテーブルや、バックアップの頻度が低いテーブルに役立ちます。 詳細は、Making a Partial Backup を参照してください。File-per-table テーブルスペースでは、テーブルスペースデータファイルのサイズをモニタリングすることによって、ファイルシステム上のテーブルサイズをモニタリングできます。
innodb_flush_method
がO_DIRECT
に設定されている場合、共通の Linux ファイルシステムでは、共有テーブルスペースデータファイルなどの単一ファイルへの同時書込みは許可されません。 その結果、file-per-table テーブルスペースをこの設定と組み合わせて使用すると、パフォーマンスが向上する可能性があります。共有テーブルスペース内のテーブルのサイズは、64TB のテーブルスペースサイズ制限によって制限されます。 比較すると、各 file-per-table テーブルスペースには 64TB のサイズ制限があり、個々のテーブルのサイズを大きくするための十分な容量が提供されます。
File-per-table テーブルスペースには、システムテーブルスペースや一般テーブルスペースなどの共有テーブルスペースと比較して、次のデメリットがあります。
file-per-table テーブルスペースでは、同じテーブルの行によってのみ利用できる未使用の領域が各テーブルに存在する可能性があるため、適切に管理されていない場合は領域が無駄になる可能性があります。
fsync
操作は、単一の共有テーブルスペースデータファイルではなく、複数のファイルごとのデータファイルに対して実行されます。fsync
操作はファイル単位であるため、複数のテーブルに対する書込み操作を組み合せることはできないため、fsync
操作の合計数が増加する可能性があります。mysqld では、file-per-table テーブルスペースごとにオープンファイルハンドルを保持する必要があります。file-per-table テーブルスペースに多数のテーブルがある場合、パフォーマンスに影響する可能性があります。
各テーブルに独自のデータファイルがある場合は、さらにファイル記述子が必要です。
断片化が増える可能性があるため、
DROP TABLE
およびテーブルスキャンのパフォーマンスが低下する可能性があります。 ただし、断片化が管理されている場合、file-per-table テーブルスペースを使用すると、これらの操作のパフォーマンスを向上させることができます。file-per-table テーブルスペースに存在するテーブルを削除すると、バッファープールがスキャンされます。これは、バッファープールが大きい場合には数秒かかることがあります。 スキャンは広範囲に内部ロックをかけて実行されるため、他の操作を遅らせる場合があります。
自動拡張共有テーブルスペースファイルがいっぱいになったときにそのサイズを拡張する増分サイズを定義する
innodb_autoextend_increment
変数は、innodb_autoextend_increment
設定に関係なく自動拡張される file-per-table テーブルスペースファイルには適用されません。 初期 file-per-table テーブルスペース拡張は少量であり、その後、拡張は 4MB 単位で行われます。