DELETE removes one or many rows from a SQL Server table based on an optional filter.
DELETE removes selected rows from a table and writes each change to the transaction log, allowing precise rollbacks and auditing.
DELETE supports WHERE filters, fires triggers, and keeps identity values; TRUNCATE wipes the whole table, skips row-by-row logging, and resets identities.
Filter by the primary key to remove a single record. Verify with a SELECT before committing.
DELETE FROM Customers
WHERE id = 42;
Combine DELETE with a date filter to purge old data while keeping recent orders intact.
DELETE FROM Orders
WHERE order_date < '2023-01-01';
Alias the target table after DELETE and join to related data to match rows safely.
DELETE o
FROM Orders AS o
JOIN Customers AS c ON c.id = o.customer_id
WHERE c.email LIKE '%@example.com';
Add a foreign-key constraint with ON DELETE CASCADE so child OrderItems
vanish automatically when an Orders
row is deleted.
Wrap deletes in a transaction, run the same filter with SELECT first, back up data, delete in manageable batches, and index filter columns.
Missing WHERE deletes everything—always include a filter. Forgetting to COMMIT leaves locks—issue COMMIT or ROLLBACK. Deleting without supporting indexes causes slow scans—create indexes on search columns.
Yes. If you wrapped the DELETE in a transaction, issue ROLLBACK
before committing. After COMMIT, you’ll need backups or point-in-time recovery.
Use a CTE with ROW_NUMBER() to keep the first occurrence and delete rows where the row number > 1.
Usually. DELETE logs every row, fires triggers, and maintains constraints, so it’s slower than TRUNCATE, which is minimally logged and ignores most constraints.