テスターは、新たなテストを実行する前にステージング テーブルをクリアしたいと考えています。 DELETE、TRUNCATE、DROPのどれにするべきですか?選択を誤ると、ジョブが遅くなったり、テーブルが欠落したり、本番環境では非常に悪い午後になったりする可能性があります。

以下の DELETE および DROP の例を SQLite 3.50 で実行し、出力はその実行から得られます。 SQLite には TRUNCATE コマンドがないため、TRUNCATE のメモは独自のテストではなく、PostgreSQL、MySQL、および SQL Server の公式ドキュメントに基づいています。

短い答え

• いくつか行を削除する必要がありますか? DELETE ... WHEREを使用します。
• テーブルを空にしたままにしておく必要がありますか?サポートされている場合は TRUNCATE を使用してください。
• テーブルを完全になくす必要がありますか? DROP TABLEを使用します。

DELETE: 行を削除します

DELETE はデータ変更 (DML) コマンドです。一度に 1 行ずつ削除し、行レベルのトリガーを起動し、フィルター処理することができます。監査トリガーを備えた小さなテーブルを設定します。

CREATE TABLE logs (id INTEGER PRIMARY KEY AUTOINCREMENT, level TEXT);
INSERT INTO logs (level) VALUES ('INFO'),('ERROR'),('INFO'),('DEBUG');

CREATE TABLE audit (msg TEXT);
CREATE TRIGGER logs_delete AFTER DELETE ON logs
BEGIN INSERT INTO audit VALUES ('deleted ' || OLD.id); END;

DELETE FROM logs WHERE level = 'DEBUG';

SELECT id, level FROM logs;  -- (1,'INFO'), (2,'ERROR'), (3,'INFO')
SELECT * FROM audit;         -- 'deleted 4'

一致する行のみが実行され、トリガーがそれを記録しました。 WHERE 句を指定せずに DELETE FROM logs を実行すると、他の 3 行が削除され、監査テーブルには、削除された行ごとに 1 つずつ、合計 4 つのエントリが保持されました。

DELETE は自動インクリメントカウンターをリセットしません。テーブルを空にした後、次の挿入は 1 ではなく id 5 を受け取りました。SQLite では、これは AUTOINCREMENT が原因です。 MySQL InnoDB および SQL Server の ID 列も、DELETE 後の位置から続行されます。

TRUNCATE: テーブルを空にします

TRUNCATE TABLE logs; はすべての行を一度に削除します。 WHERE 句を使用することはできません。通常、データベースは行を 1 つずつ削除するのではなく、テーブルのデータ ページを解放します。そのため、大規模なテーブルでは処理がはるかに高速になります。

SQLite で実行すると、SQLite には次のコマンドがないため、構文エラーが発生しました。

TRUNCATE TABLE logs;
-- near "TRUNCATE": syntax error

SQLite では、WHERE 句なしで DELETE FROM logs; を使用します。 SQLite のドキュメントには、テーブルにトリガーがない場合にこれを高速化する「切り捨て最適化」について説明されています。このテーブルにはトリガーがあったため、削除は行ごとに実行され、行ごとに実行されました。

TRUNCATE をサポートするデータベースでは、ドキュメントによると次のようになります。

• 通常はそうなりますそうではない行レベルの DELETE トリガーを起動します。
• 通常、MySQL や SQL Server などの ID または自動インクリメント カウンターがリセットされます。 PostgreSQL では RESTART IDENTITY を追加します。
• ほとんどのシステムでは、DELETE よりも強力な権限が必要です。

DROP: テーブル自体を削除します

DROP TABLE はスキーマ (DDL) コマンドです。データ、テーブル定義、そのインデックス、トリガー、制約が削除されます。ビューや外部キーなど、テーブルを参照するものすべても影響を受けます。

DROP TABLE logs;
SELECT * FROM logs;
-- no such table: logs

DROP TABLE IF EXISTS logs;  -- no error, even though it is gone

IF EXISTS は、複数回実行されるセットアップ スクリプトで便利です。 SQL ビューの説明 で示したように、ドロップされたテーブルのビューは壊れる可能性があります。

比較表

ロールバックできますか?

多くの記事が過度に単純化しているのはこの点です。正直な答えは、それはデータベースに依存するということです。

DELETE はトランザクション内であればどこでもロールバックできます。私たちはそれをテストしました:

BEGIN;
DELETE FROM logs;
SELECT COUNT(*) FROM logs;  -- 0
ROLLBACK;
SELECT COUNT(*) FROM logs;  -- 3

DROP も、トランザクション DDL をサポートする SQLite でロールバックされました。

BEGIN;
DROP TABLE logs;
ROLLBACK;
SELECT COUNT(*) FROM logs;  -- 1 (the table is back)

他のデータベースの TRUNCATE と DROP については、ドキュメントによると次のようになります。

したがって、「TRUNCATE は決してロールバックできない」は PostgreSQL と SQL Server では誤りであり、「いつでもロールバックできる」は MySQL では誤りです。トランザクション外では、バックアップがなければそれらを元に戻すことはできません。

TRUNCATE が速い理由

DELETE は、削除された各行をログに記録して、変更を元に戻して複製できるようにし、トリガーを起動して行ごとに制約をチェックします。数百万行のテーブルでは、大量の作業とログの量が発生します。 TRUNCATE は通常、1 回の操作でストレージの割り当てを解除し、ログの量を大幅に減らします。すべてではなく大きなサブセットを削除するには、長時間のロックを避けるためにバッチで削除します。ロックとクエリのコストについては、SQL クエリの最適化 で説明します。

外部キーと権限

• 外部キー。 SQL Server は、外部キーによって参照されるテーブルの TRUNCATE を拒否します。 PostgreSQL では、参照テーブルも切り詰めるか、CASCADE を使用する必要があります。 DELETE では、代わりに制約に対して各行をチェックします。
• 権限。 DELETE には削除権限が必要です。多くの場合、TRUNCATE には ALTER または専用の TRUNCATE 権限が必要で、DROP にはスキーマに対する所有権または ALTER が必要です。
• レプリケーションと監査。 他のシステムが行レベルの変更ログまたはトリガーに依存している場合、TRUNCATE はそれらをスキップする可能性があります。まずはそれらのシステムの所有者に問い合わせてください。

どれを使うか

テスト データの場合、ID をリセットしてテストを反復可能にする TRUNCATE が一般的です。ロールバックされるトランザクションで各テストをラップすることも別のオプションであり、SQL トランザクションと ACID で説明されています。

安全チェックリスト

1. 接続しているデータベースと環境を確認してください。
2. 最初に WHERE 句を SELECT として実行します。
3. データベースがサポートしているトランザクション内で変更をラップします。
4. 運用環境で TRUNCATE または DROP を実行する前に、テスト済みの最新のバックアップを作成してください。
5. DROP ステートメントは、アドホック コンソールではなく、レビュー済みの移行スクリプトに含めてください。
6. テーブルを削除する前に、ビュー、外部キー、レポートなど、テーブルに依存するものを確認してください。

大量のデータを安全に削除する

1 回の DELETE で数百万行を削除すると、テーブルが長時間ロックされ、トランザクション ログがいっぱいになり、レプリケーションが遅くなる可能性があります。一般的なパターンは、小さなバッチで削除し、何も残らなくなるまで繰り返すことです。

-- SQL Server style (not run for this article)
DELETE TOP (5000) FROM logs WHERE created_at < '2026-01-01';

-- PostgreSQL style (not run for this article)
DELETE FROM logs
WHERE id IN (SELECT id FROM logs WHERE created_at < '2026-01-01' LIMIT 5000);

ゼロ行が報告されるまで、バッチ間に短い一時停止を挟みながら、ステートメントをループで実行します。各バッチは小さなトランザクションであるため、ロックは短く、他のクエリは実行され続けます。フィルター列のインデックス (ここでは created_at) により、すべてのバッチが高速に保たれます。

ログやイベントなど、日付ごとに増加するデータの場合は、テーブル パーティショニング の方がさらに優れています。各月は独自のパーティションに存在し、古いデータの削除は、行を 1 つずつ削除するのではなく、1 つのパーティションを削除または切り捨てる簡単な操作になります。

論理的な削除

多くのアプリケーションはビジネス レコードを物理的に削除しません。 deleted_at などの列を追加して代わりに設定し、クエリを deleted_at IS NULL でフィルター処理します。論理的な削除により回復が容易になり、監査用に履歴が保存されますが、すべてのクエリでフィルターを記憶する必要があり、これは ビュー にとって適切な仕事です。論理的に削除された行にはその値がまだ保持されているため、一意の制約にも注意が必要です。プライバシー法では、一定期間後に個人データを実際に削除することが求められる場合があるため、論理的な削除は保持ポリシーの代わりにはなりません。

まとめ

DELETE は正確かつ慎重なツールです。 TRUNCATE は高速リセット ボタンで、DROP はテーブルを完全に削除します。最大のリスクは、特にロールバックに関して、あるデータベースが別のデータベースと同じように動作すると想定することです。疑問がある場合は、まず独自のデータベース内のテーブルのコピーでコマンドをテストしてください。

よくある質問

学び続ける