SQL DROP INDEX permanently deletes an index object. Once executed and committed, the index definition, its on-disk structures, and its statistics are removed. Query planners will no longer consider that index when generating execution plans. In PostgreSQL, the command can include IF EXISTS to avoid errors if the index is absent and CASCADE to drop objects (such as materialized views) that depend on it. The operation requires exclusive lock on the index and may briefly block concurrent DML. Dropping an index that backs a PRIMARY KEY or UNIQUE constraint is not allowed; use ALTER TABLE ... DROP CONSTRAINT instead. Because rebuilding a large index can be time-consuming, a common workflow is to DROP INDEX before bulk loads and recreate it afterward. In production, always verify that no critical queries rely on the index before removing it.
index_name
(identifier) - Name of the index to drop.IF EXISTS
(keyword) - Skip error if the index does not exist (PostgreSQL, SQL Server 2016+).CONCURRENTLY
(keyword) - Drops index without locking writes but is slower (PostgreSQL).CASCADE | RESTRICT
(keyword) - Control dropping of dependent objects (PostgreSQL).ON table_name
(identifier) - Table owning the index (required in MySQL and SQL Server).ALGORITHM / LOCK
(options) - Fine-tune online drop behavior in MySQL.CREATE INDEX, ALTER INDEX, REINDEX, DROP TABLE, DROP CONSTRAINT
SQL:1999
No. A primary key is enforced by a UNIQUE constraint. Use ALTER TABLE ... DROP CONSTRAINT to remove it; DROP INDEX will fail.
Yes. PostgreSQL and Oracle allow a comma-separated list of index names in a single DROP INDEX statement.
In PostgreSQL use DROP INDEX CONCURRENTLY; in MySQL use ALGORITHM = INPLACE LOCK = NONE; in SQL Server use ONLINE = ON when rebuilding rather than dropping.
Typically the index owner or a superuser/DBA role can drop an index. In SQL Server, you need ALTER permission on the table or membership in db_ddladmin.