MySQL 8.0 リファレンスマニュアル MySQL NDB Cluster 8.0 を含む

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

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 と異なります:

テーブルに対する 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 設定にディレクトリを追加します。