DROP TABLE SQL: Cara Aman Menghapus Tabel

DROP TABLE adalah perintah SQL yang ngehapus seluruh tabel — datanya, kolomnya, index-nya, semuanya — dari database.

Beda sama DELETE yang cuma ngosongin isi. Habis DROP, tabelnya beneran nggak ada lagi. Query yang nyebut nama tabel itu langsung error.

Dan di MySQL, perintah ini nggak bisa di-rollback. Sekali jalan, ya udah.

Apa sintaks DROP TABLE?

Bentuk dasarnya satu baris:

DROP TABLE nama_tabel;

Tapi jangan pernah nulis kayak gitu di script yang bakal dijalanin berulang. Kalau tabelnya udah nggak ada, query-nya error dan script-mu berhenti di tengah.

Versi yang aman:

DROP TABLE IF EXISTS staging_penjualan;

IF EXISTS bikin database diem aja kalau tabelnya nggak ketemu. Nggak ada error, script lanjut.

Beberapa tabel sekaligus? Pisahin pakai koma:

DROP TABLE IF EXISTS staging_a, staging_b, staging_c;

Apa bedanya DROP, TRUNCATE, dan DELETE?

Tiga perintah ini sering ketuker, dan salah pilih bisa bikin kerjaan seharian ilang.

	DROP	TRUNCATE	DELETE
Tabel masih ada setelahnya?	Nggak	Ya (kosong)	Ya
Bisa pilih baris tertentu?	Nggak	Nggak	Ya, pakai WHERE
Kecepatan di tabel gede	Cepat	Cepat	Lambat
Reset auto increment?	—	Ya	Nggak
Bisa rollback?	Tergantung DB	Tergantung DB	Ya
Trigger jalan?	Nggak	Nggak	Ya

Aturan praktisnya:

• Mau isi ulang tabel yang sama tiap hari → TRUNCATE.
• Mau hapus baris tertentu → DELETE ... WHERE.
• Tabelnya udah nggak dipakai lagi selamanya → DROP.

Kalau kamu ragu, hampir pasti yang kamu butuhin bukan DROP. Penjelasan lengkap perintah pembersihan data ada di halaman fungsi TRUNCATE TABLE dan halaman fungsi DELETE.

Kenapa DROP TABLE gagal karena foreign key?

Error-nya kira-kira gini:

ERROR: cannot drop table produk because other objects depend on it
DETAIL: constraint transaksi_produk_id_fkey on table transaksi depends on table produk

Artinya, ada tabel transaksi yang nyantol ke produk lewat foreign key. Database nolak ngehapus, biar nggak ada baris yang nunjuk ke tabel hantu.

Ini fitur pengaman, bukan bug. Jangan buru-buru diakalin.

Cek dulu siapa aja yang bergantung ke tabelmu:

SELECT
  tc.table_name   AS tabel_anak,
  kcu.column_name AS kolom_fk
FROM information_schema.table_constraints tc
JOIN information_schema.key_column_usage kcu
  ON tc.constraint_name = kcu.constraint_name
JOIN information_schema.constraint_column_usage ccu
  ON tc.constraint_name = ccu.constraint_name
WHERE tc.constraint_type = 'FOREIGN KEY'
  AND ccu.table_name = 'produk';

Kalau hasilnya kosong, aman. Kalau ada isinya, kamu punya dua pilihan.

Pilihan 1 — hapus dulu constraint di tabel anak:

ALTER TABLE transaksi DROP CONSTRAINT transaksi_produk_id_fkey;
DROP TABLE produk;

Pilihan 2 — pakai CASCADE (PostgreSQL):

DROP TABLE produk CASCADE;

CASCADE ngehapus semua objek yang bergantung: constraint, view, materialized view. Ini yang paling sering bikin orang kaget — mereka pikir cuma satu tabel yang kehapus, ternyata 3 view laporan ikut ilang.

Aku sendiri hampir nggak pernah pakai CASCADE di production tanpa ngecek daftar dependensinya duluan.

Apakah DROP TABLE bisa di-undo?

Jawabannya beda-beda per database, dan ini penting banget.

Database	Bisa ROLLBACK?
PostgreSQL	Ya, selama masih dalam transaksi
SQL Server	Ya, selama masih dalam transaksi
MySQL (InnoDB)	Nggak — implicit commit
SQLite	Ya, dalam transaksi
BigQuery	Nggak, tapi ada time travel 7 hari

Di PostgreSQL, kamu bisa pasang jaring pengaman:

BEGIN;
DROP TABLE produk;

-- cek dampaknya dulu di sini
-- kalau ternyata salah:
ROLLBACK;

-- kalau udah yakin:
COMMIT;

Di MySQL, jaring ini nggak ada. Begitu kamu tekan Enter, tabelnya lenyap. Satu-satunya jalan pulih adalah restore dari backup — yang artinya kamu harus punya backup duluan.

Contoh kasus: bersihin tabel staging toko_berkah

Pipeline harian toko_berkah bikin tabel staging tiap kali data kasir masuk. Setelah 3 bulan, ada 47 tabel staging_* nyampah di database, total 2,1 GB.

Cara aku bersihinnya — dan ini pola yang aku pakai tiap kali:

Langkah 1: lihat dulu apa yang mau kehapus. Jangan langsung DROP.

SELECT
  table_name,
  pg_size_pretty(pg_total_relation_size(quote_ident(table_name))) AS ukuran
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_name LIKE 'staging_%'
ORDER BY pg_total_relation_size(quote_ident(table_name)) DESC;

Langkah 2: backup yang masih ragu.

CREATE TABLE staging_penjualan_backup_20260307 AS
SELECT * FROM staging_penjualan;

Langkah 3: rename, jangan langsung drop.

ALTER TABLE staging_penjualan RENAME TO zz_deprecated_staging_penjualan;

Tunggu seminggu. Kalau nggak ada dashboard yang error dan nggak ada yang komplain, baru:

DROP TABLE IF EXISTS zz_deprecated_staging_penjualan;

Hasilnya: 2,1 GB balik, query planner jadi lebih cepat, dan yang paling penting — nol insiden.

Dari 47 tabel yang aku rename, ternyata 3 di antaranya masih dipakai sama sebuah dashboard mingguan yang aku nggak tau ada. Kalau aku langsung DROP, tiga laporan itu mati tanpa jalan pulih.

Rename dulu itu yang nyelametin.

Checklist 5 langkah sebelum DROP di production

1. Cek nama tabelnya dua kali. Serius. orders dan orders_archive beda satu kata.
2. Cari dependensinya lewat information_schema — foreign key, view, materialized view.
3. Backup: CREATE TABLE x_backup AS SELECT * FROM x;
4. Rename dulu, tunggu 7 hari, baru DROP.
5. Jalanin di staging duluan, jangan langsung di production.

Langkah 4 yang paling sering dilewat, dan itu justru yang paling murah.

Kesalahan umum

Lupa WHERE-nya nggak ada. DROP TABLE nggak nerima WHERE. Kalau kamu cuma mau hapus data 2024, yang kamu butuhin DELETE FROM x WHERE tahun = 2024.

Nge-DROP di koneksi yang salah. Kejadian klasik: tab SQL client-nya masih nyambung ke production padahal kamu pikir itu staging. Bikin warna tema beda buat tiap environment.

Pakai CASCADE tanpa cek. Kamu pikir hapus 1 tabel, ternyata 5 view ikut kebawa.

Ngira TRUNCATE lebih bahaya dari DROP. Kebalik. TRUNCATE nyisain strukturnya — tabelnya masih bisa langsung diisi lagi.

Buat detail sintaks lengkap termasuk opsi RESTRICT dan CASCADE, dokumentasi resmi PostgreSQL ada di halaman DROP TABLE.

FAQ

Apa itu DROP TABLE di SQL?

DROP TABLE adalah perintah SQL yang ngehapus tabel secara utuh — baris datanya, definisi kolomnya, index, trigger, dan constraint-nya sekalian. Setelah dijalankan, tabelnya hilang dari database dan query yang nyebut nama tabel itu bakal error.

Apa bedanya DROP, TRUNCATE, dan DELETE?

DROP ngehapus tabel beserta strukturnya. TRUNCATE ngosongin semua baris tapi tabelnya tetep berdiri dengan kolom yang sama. DELETE ngehapus baris satu per satu dan bisa dikasih WHERE buat milih baris tertentu. Kalau kamu cuma mau isi ulang tabel yang sama, pakai TRUNCATE.

Apakah DROP TABLE bisa di-undo?

Di PostgreSQL dan SQL Server, DROP TABLE bisa dibatalin lewat ROLLBACK selama masih di dalam transaksi yang belum di-COMMIT. Di MySQL dengan InnoDB, DROP TABLE bersifat implicit commit — begitu jalan, langsung permanen. Satu-satunya jalan pulih di MySQL adalah restore dari backup.

Kenapa DROP TABLE gagal karena foreign key?

Karena ada tabel lain yang nyantol lewat foreign key. Database nolak biar nggak ninggalin referensi yang nunjuk ke tabel hantu. Solusinya: hapus dulu constraint di tabel anaknya, atau pakai DROP TABLE produk CASCADE. Hati-hati sama CASCADE — dia ikut ngehapus view yang bergantung.

Gimana cara aman jalanin DROP TABLE di production?

Backup dulu pakai CREATE TABLE x_backup AS SELECT * FROM x. Lalu cek dependensinya lewat information_schema. Rename dulu tabelnya jadi zz_deprecated_x dan tunggu seminggu — kalau nggak ada yang komplain, baru DROP.

Penutup

Tiga hal yang bikin kamu aman:

• Selalu pakai IF EXISTS di script yang dijalanin berulang.
• Rename dulu, tunggu seminggu, baru DROP.
• Di MySQL nggak ada ROLLBACK buat DROP — backup itu satu-satunya jaring.

Latihan perintah DDL langsung di browser bisa kamu mulai di halaman fungsi CREATE TABLE — bikin dulu, baru berani hapus.

Lanjut baca: tipe data SQL: panduan memilih VARCHAR, INT, DATE, DECIMAL.