SQLのDELETEとTRUNCATEの違いを徹底解説！使い分けのポイントと注意点

「SQLでテーブルのデータを削除したいけど、DELETEとTRUNCATEって何が違うの？」
「どっちを使えばいいのか分からない…」

データベースを扱っていると、必ず出てくるこの疑問。どちらもデータを削除するコマンドですが、実は動作や特性が大きく異なるんです。

この記事では、SQLのDELETEとTRUNCATEの違いについて、初心者にも分かりやすく解説していきます。それぞれの特徴を理解すれば、状況に応じて適切なコマンドを選べるようになりますよ。

DELETEとTRUNCATEの基本的な違い
1. DELETE文とは
2. TRUNCATE文とは
主な違いを比較表で確認
動作の違いを詳しく解説
1. DELETEの動作
2. TRUNCATEの動作
パフォーマンスの違い
1. DELETEのパフォーマンス
2. TRUNCATEのパフォーマンス
トランザクションとロールバック
1. DELETEのトランザクション
2. TRUNCATEのトランザクション
自動採番（AUTO_INCREMENT）の扱い
1. DELETEの場合
2. TRUNCATEの場合
トリガーの実行
1. DELETEとトリガー
2. TRUNCATEとトリガー
外部キー制約との関係
1. DELETEと外部キー
2. TRUNCATEと外部キー
必要な権限の違い
1. DELETE権限
2. TRUNCATE権限
使い分けのポイント
1. DELETEを使うべき場合
2. TRUNCATEを使うべき場合
実践的な使用例
注意点とベストプラクティス
よくある質問と回答
まとめ

DELETEとTRUNCATEの基本的な違い

まず、2つのコマンドの基本的な違いを押さえましょう。

DELETE文とは

DELETEは、テーブルから行（レコード）を削除するSQL文です。

基本構文：

DELETE FROM テーブル名 WHERE 条件;

特徴：

条件を指定して、特定の行だけを削除できる
WHERE句がない場合は全ての行を削除
1行ずつ処理される
トランザクションログに記録される

TRUNCATE文とは

TRUNCATEは、テーブルの全てのデータを一括削除するSQL文です。

基本構文：

TRUNCATE TABLE テーブル名;

特徴：

テーブル内の全データを削除
条件指定はできない（必ず全削除）
高速に動作する
最小限のログしか記録されない

簡単に言うと、DELETEは「消しゴムで1つずつ消す」イメージで、TRUNCATEは「ページごと破って捨てる」イメージですね。

主な違いを比較表で確認

分かりやすく表にまとめてみました。

項目	DELETE	TRUNCATE
削除範囲	条件指定で部分削除可能	全データを削除のみ
WHERE句	使用可能	使用不可
速度	遅い	速い
ログ記録	全行をログに記録	最小限のログ
ロールバック	可能（通常）	不可能（データベースによる）
自動採番リセット	リセットされない	リセットされる
トリガー	実行される	実行されない
権限	DELETE権限	テーブル所有者権限が必要

この違いを理解することが、使い分けのポイントになります。

動作の違いを詳しく解説

それぞれの動作について、もう少し詳しく見ていきましょう。

DELETEの動作

DELETEは、DML（Data Manipulation Language：データ操作言語）に分類されるコマンドです。

具体的な動作：

WHERE句で条件に一致する行を検索
該当する行を1行ずつ削除
各削除操作をトランザクションログに記録
DELETEトリガーがあれば実行
削除した行数を返す

実行例：

-- 特定の条件で削除
DELETE FROM users WHERE age < 18;

-- 全て削除（WHERE句なし）
DELETE FROM users;

DELETEは柔軟性が高く、細かい制御ができるのが強みです。

TRUNCATEの動作

TRUNCATEは、DDL（Data Definition Language：データ定義言語）に分類されるコマンドです。

具体的な動作：

テーブル内の全データページを一括解放
最小限のログのみ記録
トリガーは実行されない
自動採番（AUTO_INCREMENT）をリセット
処理完了を返す（削除行数は返さない）

実行例：

-- テーブルの全データを削除
TRUNCATE TABLE users;

TRUNCATEは速度を重視した、大胆な削除方法なんですね。

パフォーマンスの違い

実際の処理速度はどれくらい違うのでしょうか。

DELETEのパフォーマンス

DELETEは、行数が多いほど時間がかかります。

時間がかかる理由：

1行ずつ削除処理を実行
全ての削除操作をログに記録
インデックスの更新
トリガーの実行
外部キー制約のチェック

目安：

数百行程度：問題なし
数千行以上：少し時間がかかる
数万行以上：かなり時間がかかる可能性

大量データの削除には向いていません。

TRUNCATEのパフォーマンス

TRUNCATEは、データ量に関わらず非常に高速です。

速い理由：

データページごと一括削除
ログ記録が最小限
トリガーを実行しない
行単位の処理が不要

目安：

数百行：DELETEとあまり変わらない
数千行：DELETEより明らかに速い
数万行以上：圧倒的に速い

データ量が多いほど、TRUNCATEの優位性が際立ちます。

実測例（参考）：

100万行のテーブル
DELETE：数分〜数十分
TRUNCATE：数秒

この差は非常に大きいですね。

トランザクションとロールバック

データベース操作で重要なトランザクション処理について見ていきましょう。

DELETEのトランザクション

DELETEは通常のトランザクション内で動作します。

基本的な動作：

BEGIN TRANSACTION;

DELETE FROM orders WHERE order_date < '2020-01-01';

-- 問題があればロールバック
ROLLBACK;

-- 問題なければコミット
COMMIT;

特徴：

COMMITするまで確定しない
ROLLBACKで元に戻せる
他のSQL文と組み合わせられる

ミスしても取り消せるので安全ですね。

TRUNCATEのトランザクション

TRUNCATEのトランザクション処理は、データベースによって扱いが異なります。

データベース別の動作：

MySQL（InnoDB）：

トランザクション内で使用可能
ROLLBACKで元に戻せる

START TRANSACTION;
TRUNCATE TABLE test_table;
ROLLBACK;  -- 戻せる

PostgreSQL：

トランザクション内で使用可能
ROLLBACKで元に戻せる

SQL Server：

暗黙的にコミットされる
ROLLBACKで戻せない
トランザクション境界を越える

Oracle：

暗黙的にコミットされる
ROLLBACKで戻せない
DDL文として扱われる

使っているデータベースの仕様を確認することが重要です。

自動採番（AUTO_INCREMENT）の扱い

主キーの自動採番がどうなるかも、大きな違いです。

DELETEの場合

DELETEでは、自動採番カウンターはリセットされません。

動作例：

-- 最後のIDが100だったとする
DELETE FROM products;  -- 全削除

-- 新しいレコードを追加
INSERT INTO products (name) VALUES ('新商品');
-- IDは101から始まる

特徴：

削除前の連番が保持される
次の挿入は続きの番号から
連番に欠番が生じる

歴史を保持したい場合に適しています。

TRUNCATEの場合

TRUNCATEでは、自動採番カウンターが初期化されます。

動作例：

-- 最後のIDが100だったとする
TRUNCATE TABLE products;  -- 全削除

-- 新しいレコードを追加
INSERT INTO products (name) VALUES ('新商品');
-- IDは1から始まる

特徴：

カウンターが1にリセット
完全に新しいテーブルのような状態
連番がきれいに続く

テーブルを完全にリセットしたい場合に適しています。

トリガーの実行

トリガー（特定の操作時に自動実行される処理）の扱いも異なります。

DELETEとトリガー

DELETEでは、DELETEトリガーが実行されます。

トリガー例：

-- トリガーの定義
CREATE TRIGGER before_delete_user
BEFORE DELETE ON users
FOR EACH ROW
BEGIN
    -- 削除ログを記録
    INSERT INTO delete_log (user_id, deleted_at) 
    VALUES (OLD.user_id, NOW());
END;

-- DELETEを実行するとトリガーが動く
DELETE FROM users WHERE user_id = 123;
-- → delete_logにも記録される

メリット：

削除の履歴を残せる
関連データの整合性を保てる
ビジネスロジックを実行できる

TRUNCATEとトリガー

TRUNCATEでは、トリガーは実行されません。

動作：

-- 同じトリガーが定義されていても
TRUNCATE TABLE users;
-- → delete_logには何も記録されない

注意点：

削除ログが残らない
関連処理がスキップされる
ビジネスロジックが実行されない

トリガーに依存している場合は、TRUNCATEの使用に注意が必要です。

外部キー制約との関係

外部キー制約がある場合の動作も確認しましょう。

DELETEと外部キー

DELETEは外部キー制約をチェックします。

例：

-- ordersテーブルがusersテーブルを参照している場合
DELETE FROM users WHERE user_id = 1;
-- → ordersに関連データがあればエラー

対応方法：

先に関連データを削除
CASCADE設定で自動削除
SET NULL設定でNULLに変更

外部キー制約により、データの整合性が保たれます。

TRUNCATEと外部キー

TRUNCATEは、外部キーで参照されているテーブルを削除できません。

動作：

-- usersテーブルが外部キーで参照されている場合
TRUNCATE TABLE users;
-- → エラーが発生

エラーメッセージ例：

MySQL: “Cannot truncate a table referenced in a foreign key constraint”
PostgreSQL: “cannot truncate a table referenced in a foreign key constraint”

回避方法：

外部キー制約を一時的に無効化（非推奨）
参照している全テーブルも同時にTRUNCATEする
DELETEを使用する

外部キーがある場合は、TRUNCATEの使用が制限されます。

必要な権限の違い

実行に必要な権限も異なります。

DELETE権限

DELETEは比較的軽い権限で実行できます。

必要な権限：

DELETE権限（テーブルに対する）

付与例：

-- 特定ユーザーにDELETE権限を付与
GRANT DELETE ON database_name.table_name TO 'user'@'localhost';

一般的なデータベースユーザーでも実行可能です。

TRUNCATE権限

TRUNCATEにはより強い権限が必要です。

必要な権限：

テーブルの所有者
または DROP権限
または ALTER権限（データベースによる）

付与例：

-- DROP権限の付与が必要
GRANT DROP ON database_name.table_name TO 'user'@'localhost';

通常のユーザーには付与されないことが多い権限です。

使い分けのポイント

どんな時にどちらを使うべきか、シーン別に見ていきましょう。

DELETEを使うべき場合

以下のような状況では、DELETEを選択しましょう。

条件：

特定の条件で一部のデータだけ削除したい
トリガーを実行する必要がある
トランザクション内で安全に操作したい
削除ログを残したい
外部キー制約のあるテーブル
自動採番を継続したい
少量のデータを削除する場合

実例：

-- 1年以上前の注文を削除
DELETE FROM orders WHERE order_date < DATE_SUB(NOW(), INTERVAL 1 YEAR);

-- 退会したユーザーのデータを削除
DELETE FROM users WHERE status = 'deleted';

-- テスト用の特定データを削除
DELETE FROM test_data WHERE test_flag = 1;

細かい制御が必要な場合はDELETEが適しています。

TRUNCATEを使うべき場合

以下のような状況では、TRUNCATEを選択しましょう。

条件：

テーブルの全データを削除したい
処理速度を重視する
大量のデータを一括削除
自動採番をリセットしたい
トリガーの実行が不要
外部キー制約がない
テストデータの初期化

実例：

-- テストテーブルの完全初期化
TRUNCATE TABLE test_users;

-- 一時テーブルのクリア
TRUNCATE TABLE temp_import_data;

-- セッションデータの一括削除
TRUNCATE TABLE sessions;

-- ログテーブルの定期削除
TRUNCATE TABLE access_logs;

速度と簡潔さを重視する場合はTRUNCATEが適しています。

実践的な使用例

実際の開発現場でよくある使用例を紹介します。

例1：テストデータのクリア

開発環境でテストデータを削除する場合。

DELETE版：

-- 条件付きで削除
BEGIN TRANSACTION;
DELETE FROM test_orders WHERE created_at < '2024-01-01';
DELETE FROM test_customers WHERE test_flag = 1;
COMMIT;

TRUNCATE版：

-- 全削除で高速
TRUNCATE TABLE test_orders;
TRUNCATE TABLE test_customers;
-- または複数同時に（PostgreSQL）
TRUNCATE TABLE test_orders, test_customers;

テスト環境ではTRUNCATEが便利です。

例2：古いログデータの削除

定期的にログを削除する場合。

DELETE版（推奨）：

-- 90日以上前のログを削除
DELETE FROM access_logs 
WHERE log_date < DATE_SUB(NOW(), INTERVAL 90 DAY);

一部だけ削除するのでDELETEを使います。

例3：ユーザーデータの削除

ユーザーの退会処理の場合。

DELETE版（必須）：

-- トリガーで履歴を残す
DELETE FROM users WHERE user_id = 123;
-- → delete_logに記録される

トリガーが必要なのでDELETEを使います。

例4：インポート用テーブルの初期化

データインポート前のテーブルクリア。

TRUNCATE版（推奨）：

-- 高速にクリア
TRUNCATE TABLE import_staging;

-- 新しいデータをインポート
LOAD DATA INFILE 'data.csv' INTO TABLE import_staging;

全削除で速度重視なのでTRUNCATEを使います。

注意点とベストプラクティス

実際に使用する際の注意点をまとめます。

DELETEの注意点

WHERE句を忘れない：

-- 危険！全削除されてしまう
DELETE FROM important_table;

-- 安全：条件を指定
DELETE FROM important_table WHERE status = 'inactive';

WHERE句のないDELETEは全削除になるので要注意です。

大量データの削除は分割：

-- 一度に削除すると重い
DELETE FROM large_table WHERE created_at < '2020-01-01';  -- 100万行

-- 分割して削除
DELETE FROM large_table WHERE created_at < '2020-01-01' LIMIT 10000;
-- 複数回実行

負荷を分散させる工夫が必要です。

TRUNCATEの注意点

取り消せないことを理解：

-- データベースによってはロールバック不可
TRUNCATE TABLE important_data;
-- → 取り返しがつかない可能性

本番環境では慎重に使用しましょう。

外部キーの確認：

-- 事前に外部キー制約を確認
SHOW CREATE TABLE table_name;

-- または
SELECT * FROM information_schema.KEY_COLUMN_USAGE 
WHERE TABLE_NAME = 'table_name';

参照されているテーブルは削除できません。

共通の注意点

バックアップの確認：

本番データベースで実行する前に必ずバックアップ
削除操作は不可逆的

権限の確認：

実行権限があるか事前に確認
本番環境では権限を制限

トランザクションの活用：

-- 安全な削除パターン
BEGIN TRANSACTION;

-- 削除実行
DELETE FROM users WHERE inactive = 1;

-- 結果を確認
SELECT COUNT(*) FROM users;

-- 問題なければコミット、問題あればロールバック
COMMIT;  -- または ROLLBACK;

よくある質問と回答

Q1. TRUNCATEの方が速いなら、常にTRUNCATEを使うべき？

A. いいえ、状況によります。全削除でトリガーやログが不要な場合のみTRUNCATEを使いましょう。条件指定が必要な場合や、外部キー制約がある場合はDELETEを使う必要があります。

Q2. DELETE文でWHERE句を忘れたらどうなる？

A. テーブルの全データが削除されます。非常に危険なので、本番環境では必ずWHERE句を確認してから実行しましょう。多くのクライアントツールには確認ダイアログが表示されます。

Q3. TRUNCATEしたデータは復元できる？

A. データベースによります。MySQLのInnoDBやPostgreSQLではトランザクション内ならROLLBACK可能ですが、SQL ServerやOracleでは基本的に復元できません。必ずバックアップを取ってから実行しましょう。

Q4. 数千行のデータを削除する場合、どちらを使うべき？

A. 全削除ならTRUNCATEが圧倒的に速いです。条件付き削除ならDELETEを使いますが、可能であればLIMIT句で分割削除すると負荷を軽減できます。

Q5. DELETEとDROPの違いは？

A. DELETEはテーブルの行を削除しますが、テーブル構造は残ります。DROPはテーブル自体を削除します。TRUNCATEはその中間で、構造を残してデータだけ削除する感じです。

Q6. TRUNCATEはロックをかける？

A. はい、TRUNCATEはテーブル全体をロックします。ただし、1行ずつ処理するDELETEよりも処理時間が短いため、ロック時間も短くなる傾向があります。

まとめ

SQLのDELETEとTRUNCATEの違いについてまとめます。

DELETE文：

条件指定で部分削除が可能
トランザクション対応
トリガーが実行される
ロールバック可能
自動採番は継続
処理速度は遅め
細かい制御が必要な場合に使用

TRUNCATE文：

テーブル全体を削除のみ
高速処理
トリガーは実行されない
ロールバック不可（DBによる）
自動採番がリセット
外部キー制約がある場合は使用不可
テーブルの完全初期化に使用

使い分けの基本：

条件付き削除 → DELETE
全削除で速度重視 → TRUNCATE
トリガー必要 → DELETE
外部キー制約あり → DELETE
テスト環境の初期化 → TRUNCATE

それぞれの特性を理解して、適切に使い分けることが大切です。特に本番環境では、バックアップを取ってから慎重に実行しましょう。

この記事が、あなたのデータベース操作の理解を深める手助けになれば嬉しいです。安全なSQL操作を心がけてください！

DELETEとTRUNCATEの基本的な違い

DELETE文とは

TRUNCATE文とは

主な違いを比較表で確認

動作の違いを詳しく解説

DELETEの動作

TRUNCATEの動作

パフォーマンスの違い

DELETEのパフォーマンス

TRUNCATEのパフォーマンス

トランザクションとロールバック

DELETEのトランザクション

TRUNCATEのトランザクション

自動採番（AUTO_INCREMENT）の扱い

DELETEの場合

TRUNCATEの場合

トリガーの実行

DELETEとトリガー

TRUNCATEとトリガー

外部キー制約との関係

DELETEと外部キー

TRUNCATEと外部キー

必要な権限の違い

DELETE権限

TRUNCATE権限

使い分けのポイント

DELETEを使うべき場合

TRUNCATEを使うべき場合

実践的な使用例

例1：テストデータのクリア

例2：古いログデータの削除

例3：ユーザーデータの削除

例4：インポート用テーブルの初期化

注意点とベストプラクティス

DELETEの注意点

TRUNCATEの注意点

共通の注意点

よくある質問と回答

Q1. TRUNCATEの方が速いなら、常にTRUNCATEを使うべき？

Q2. DELETE文でWHERE句を忘れたらどうなる？

Q3. TRUNCATEしたデータは復元できる？

Q4. 数千行のデータを削除する場合、どちらを使うべき？

Q5. DELETEとDROPの違いは？

Q6. TRUNCATEはロックをかける？

まとめ

Youtube

カテゴリー別人気記事

コメント