答え

DELETE と TRUNCATE は両方ともテーブルのクリーンアップツールですが、異なる方法で動作します：

DELETE は条件に基づいて行を削除します。WHERE をサポートし、ロールバック可能でトリガーを発動します。行数が多い場合は遅くなることがあります（1行ずつ）。
TRUNCATE はテーブル全体を即座にクリアします。WHERE を使用できず、行ごとにログに記録されることはなく、必ずしもトリガーを発動しません。ほとんどの場合、その操作は元に戻せず、一部のDBMSではロールバックできません。

詳細：

例：

-- 3年以上前に作成された注文を削除
DELETE FROM orders WHERE created_at < CURRENT_DATE - INTERVAL '3 years';

-- テーブルを完全にクリア（迅速に）
TRUNCATE TABLE logs;

逆に聞かれる質問

TRUNCATE 後にデータを回復できますか？

典型的な誤解：DELETE と同様に、TRUNCATE もトランザクションでロールバック可能だと考えられています。しかし、TRUNCATE は通常、ロールバックできず、UNDOもできません（例：トランザクション内での PostgreSQL を除く）。

例（ほとんどの DBMS で）：

BEGIN;
TRUNCATE TABLE orders;
ROLLBACK; -- ほとんどの DBMS では機能せず、データは失われます！

物語

本番環境のデータベースで TRUNCATE を使用して一時データを削除する代わりに TEST を使用しました。行を削除する監査トリガーは DELETE のみに反応したため、失ったデータ、時間、ユーザーに関する情報が欠落しました。インシデントの解析に影響が出ました。

物語

外部キーが存在する状態で TRUNCATE によるテーブルのクリア。SQL は参照整合性制約のためにエラーをスローし、スクリプトは完了せず、自動化が停止しました。解決策：外部キーを一時的に削除するか、DELETE を使用します。

物語

大規模なテーブルを対象とした DELETE による一括削除：長時間のロックによりデータベースが「ハングアップ」し、他のトランザクションがロックの解放を待っていました。結果 — システムの停滞。正しくは：DELETE LIMIT/OFFSET を使用するか、サポートされていればバッチを使用します。