Documentation Home
MySQL 8.0 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 36.1Mb
PDF (A4) - 36.2Mb


このページは機械翻訳したものです。

13.1.37 TRUNCATE TABLE ステートメント

TRUNCATE [TABLE] tbl_name

TRUNCATE TABLE は、テーブルを完全に空にします。 これには DROP 権限が必要です。 TRUNCATE TABLE は論理的に、すべての行を削除する DELETE ステートメントや、DROP TABLE および CREATE TABLE ステートメントのシーケンスに似ています。

高パフォーマンスを実現するために、TRUNCATE TABLE はデータを削除する DML メソッドをバイパスします。 したがって、ON DELETE トリガーは起動せず、親子外部キー関係を持つ InnoDB テーブルに対しては実行できず、DML 操作のようにロールバックできません。 ただし、アトミック DDL でサポートされているストレージエンジンを使用するテーブルでの TRUNCATE TABLE 操作は、その操作中にサーバーが停止すると、完全にコミットまたはロールバックされます。 詳細は、セクション13.1.1「アトミックデータ定義ステートメントのサポート」を参照してください。

TRUNCATE TABLEDELETE に似ているにもかかわらず、DML ステートメントではなく DDL ステートメントとして分類されます。 これは、次の点で DELETE と異なります:

  • 切り捨て操作はテーブルを削除して再作成するため、特に大きなテーブルの場合は、行を 1 つずつ削除するよりはるかに高速です。

  • 切り捨て操作は暗黙的なコミットを発生させるため、ロールバックできません。 セクション13.3.3「暗黙的なコミットを発生させるステートメント」を参照してください。

  • セッションがアクティブなテーブルロックを保持している場合は、切り詰め操作を実行できません。

  • InnoDB テーブルまたは NDB テーブルを参照する他のテーブルからの FOREIGN KEY 制約がある場合、そのテーブルに対する TRUNCATE TABLE は失敗します。 同じテーブルのカラム間の外部キー制約が許可されます。

  • 切り詰め操作は、削除された行数に対して、意味のある値を返しません。 通常の結果は0 rows affectedですが、これは情報がないものとして解釈してください。

  • テーブル定義が有効であるかぎり、データファイルまたはインデックスファイルが破損した場合でも、TRUNCATE TABLE を使用してテーブルを空のテーブルとして再作成できます。

  • AUTO_INCREMENT 値はすべて、その開始値にリセットされます。 これは、通常はシーケンス値を再利用しない MyISAMInnoDB にも当てはまります。

  • パーティションテーブルで使用した場合、TRUNCATE TABLE はパーティション化を保持します。つまり、データファイルおよびインデックスファイルは削除されて再作成されますが、パーティション定義には影響しません。

  • TRUNCATE TABLE ステートメントは、ON DELETE トリガーを起動しません。

  • 破損した InnoDB テーブルの切捨てがサポートされています。

テーブルに対する TRUNCATE TABLE は、HANDLER OPEN で開かれたそのテーブルのすべてのハンドラを閉じます。

TRUNCATE TABLE は、バイナリロギングおよびレプリケーション目的のときは、DROP TABLE とそれに続く CREATE TABLE として、つまり、DML ではなく DDL として扱われます。 これは、InnoDB またはほかのトランザクションストレージエンジン (そのトランザクション分離レベルがステートメントベースロギングを許可しない (READ COMMITTED または READ UNCOMMITTED)) を使用するときは、STATEMENT または MIXED ロギングモード使用時にステートメントがログに記録されず複製されなかった事実によります。 (Bug #36763) ただし、前述の方法で InnoDB を使用してレプリカに適用されます。

MySQL 5.7 以前では、ラージバッファプールおよび innodb_adaptive_hash_index が有効になっているシステムで TRUNCATE TABLE 操作を実行すると、テーブル適応ハッシュインデックスエントリの削除時に LRU スキャンが発生したため、システムパフォーマンスが一時的に低下する可能性がありました (Bug #68184)。 MySQL 8.0 で TRUNCATE TABLEDROP TABLE および CREATE TABLE に再マッピングすると、LRU スキャンの問題が回避されます。

TRUNCATE TABLE はパフォーマンススキーマのサマリーテーブルで使用できますが、その効果は行の削除ではなく、サマリーカラムを 0 または NULL にリセットすることです。 セクション27.12.18「パフォーマンススキーマサマリーテーブル」を参照してください。

file-per-table テーブルスペースに存在する InnoDB テーブルを切り捨てると、既存のテーブルスペースが削除され、新しいテーブルスペースが作成されます。 MySQL 8.0.21 では、テーブルスペースが以前のバージョンで作成され、不明なディレクトリに存在する場合、InnoDB は新しいテーブルスペースをデフォルトの場所に作成し、次の警告をエラーログに書き込みます: The DATA DIRECTORY の場所は既知のディレクトリにある必要があります。 DATA DIRECTORY の場所は無視され、ファイルはデフォルトの datadir location に格納されます。 既知のディレクトリは、datadirinnodb_data_home_dir および innodb_directories 変数で定義されているディレクトリです。 TRUNCATE TABLE で現在の場所にテーブルスペースを作成するには、TRUNCATE TABLE を実行する前に innodb_directories 設定にディレクトリを追加します。