MySQL in MySQL is best learned by connecting the rule to an order-management database. Start with the smallest SQL statement, observe the output, and then add one realistic constraint so the concept becomes practical.
The key habit for this lesson is to watch table rows, constraints, and indexes as it changes. That makes the topic easier to debug, easier to explain in interviews, and easier to use in real code without memorizing isolated syntax.
MySQL DELETE needs more than a syntax memory trick. The important idea is to understand deleting rows safely, WHERE conditions, backups, transactions, foreign keys, and soft-delete alternatives in the exact situation where the page topic appears, then prove the behavior with a small working example and one edge case.
The DELETE statement removes rows from a table. Always use a WHERE clause - omitting it deletes every row in the table. Run the equivalent SELECT first to confirm which rows will be removed.
-- Delete a specific row by primary key
DELETE FROM customers WHERE customer_id = 5;
-- Delete rows matching a condition
DELETE FROM orders WHERE status = 'cancelled';
-- Delete with multiple conditions
DELETE FROM products
WHERE stock = 0 AND category = 'Electronics';
-- Delete with LIMIT (remove at most N rows at a time - useful for large tables)
DELETE FROM orders
WHERE status = 'cancelled'
LIMIT 1000;
-- Preview rows before deleting (always a good practice)
SELECT * FROM orders WHERE status = 'cancelled' LIMIT 10;
-- Delete all rows (use TRUNCATE instead for better performance)
DELETE FROM order_items;
MySQL supports deleting rows from one or more tables using a JOIN. This is useful when you need to delete rows based on related data in another table.
-- DELETE with JOIN: delete order_items for cancelled orders
DELETE oi
FROM order_items oi
INNER JOIN orders o ON oi.order_id = o.order_id
WHERE o.status = 'cancelled';
-- DELETE from multiple tables in one statement
DELETE o, oi
FROM orders o
INNER JOIN order_items oi ON o.order_id = oi.order_id
WHERE o.status = 'cancelled' AND o.ordered_at < '2023-01-01';
-- DELETE with subquery
DELETE FROM customers
WHERE customer_id NOT IN (
SELECT DISTINCT customer_id FROM orders
);
TRUNCATE TABLE removes all rows much faster than DELETE because it drops and recreates the table internally, bypassing row-by-row logging. However, it cannot be rolled back in most cases and resets the AUTO_INCREMENT counter.
-- TRUNCATE: fast, resets AUTO_INCREMENT, cannot be rolled back
TRUNCATE table order_items;
-- DELETE: slower, logged, can be rolled back inside a transaction
DELETE FROM order_items;
-- Soft Delete Pattern: instead of deleting, mark rows as deleted
-- Add a deleted_at column to the table
ALTER table customers
ADD COLUMN deleted_at DATETIME DEFAULT NULL;
-- "Delete" a customer (soft delete)
UPDATE customers
SET deleted_at = NOW()
WHERE customer_id = 5;
-- Query only non-deleted customers
SELECT * FROM customers WHERE deleted_at IS NULL;
-- Restore a soft-deleted customer
UPDATE customers
SET deleted_at = NULL
WHERE customer_id = 5;
-- Permanently purge soft-deleted records older than 90 days
DELETE FROM customers
WHERE deleted_at IS NOT NULL
AND deleted_at < NOW() - INTERVAL 90 DAY;
Use MySQL when the program needs a clear answer to a specific problem, not because the keyword looks familiar. In a real MySQL task, first name the input, then name the transformation, then name the output. This small discipline shows whether the topic is being used correctly or only copied from an example.
A reliable practice flow is: create the smallest working SQL statement, add one normal case, add one edge case such as missing, repeated, empty, or boundary input, and then confirm the result with result set and EXPLAIN output. If the result surprises you, reduce the code until the behavior is visible again.
The most common trap here is copying the syntax before understanding the behavior. Avoid it by writing one sentence before the code that explains why MySQL is the right choice. After the code runs, verify the lesson by doing this: change one input and explain the changed output.
DELETE removes rows from a table. Because deleted rows may be difficult or impossible to recover, the WHERE clause is the most important part of the statement. Many applications use soft deletes, such as setting deleted_at, when business records should disappear from screens but remain available for audit or recovery.
Foreign keys can also affect DELETE behavior. A parent row may be blocked if child rows still reference it, or related rows may be deleted automatically if cascade rules exist. Before deleting, understand relationships, preview the matching rows, and decide whether hard delete or soft delete is appropriate.
START TRANSACTION;
DELETE FROM sessions
WHERE expires_at < NOW();
COMMIT;
Copying the syntax before understanding the behavior.
Write the expected behavior first, then make the example prove it.
Practicing only the perfect input.
Also test missing, repeated, empty, or boundary input before considering the lesson complete.
Looking only at the final output.
Trace table rows, constraints, and indexes through each important step.
Deleting records before checking how many rows match the condition.
Preview, count, and back up important rows before running DELETE.
Use it when the problem matches the behavior shown in the example and when the result can be verified through result set and EXPLAIN output.
Start with a tiny case, then test missing, repeated, empty, or boundary input. The main warning sign is copying the syntax before understanding the behavior.
Trace table rows, constraints, and indexes, predict the result, run the example, and compare your prediction with the actual output.
A soft delete marks a row as deleted, often with deleted_at or status, instead of physically removing it from the table.
Explore 500+ free tutorials across 20+ languages and frameworks.