DELETE
SyntaxDELETE [LOW_PRIORITY] [QUICK] FROM table_name [WHERE where_definition] [ORDER BY ...] [LIMIT row_count] or DELETE [LOW_PRIORITY] [QUICK] table_name[.*] [, table_name[.*] ...] FROM table-references [WHERE where_definition] or DELETE [LOW_PRIORITY] [QUICK] FROM table_name[.*] [, table_name[.*] ...] USING table-references [WHERE where_definition]
DELETE
deletes rows from table_name
that satisfy the condition
given by where_definition
, and returns the number of records deleted.
If you issue a DELETE
with no WHERE
clause, all rows are
deleted. If you do this in AUTOCOMMIT
mode, this works as
TRUNCATE
. See section 6.4.7 TRUNCATE
Syntax. In MySQL 3.23,
DELETE
without a WHERE
clause will return zero as the number
of affected records.
If you really want to know how many records are deleted when you are deleting
all rows, and are willing to suffer a speed penalty, you can use a
DELETE
statement of this form:
mysql> DELETE FROM table_name WHERE 1>0;
Note that this is much slower than DELETE FROM table_name
with no
WHERE
clause, because it deletes rows one at a time.
If you specify the keyword LOW_PRIORITY
, execution of the
DELETE
is delayed until no other clients are reading from the table.
For MyISAM tables,
if you specify the word QUICK
then the storage engine will not
merge index leaves during delete, which may speed up certain kind of
deletes.
The speed of delete operations may also be affected by factors discussed in
section 5.2.12 Speed of DELETE
Queries.
In MyISAM
tables, deleted records are maintained in a linked list and
subsequent INSERT
operations reuse old record positions. To
reclaim unused space and reduce file-sizes, use the OPTIMIZE
TABLE
statement or the myisamchk
utility to reorganise tables.
OPTIMIZE TABLE
is easier, but myisamchk
is faster. See
section 4.5.1 OPTIMIZE TABLE
Syntax and section 4.4.6.10 Table Optimisation.
The first multi-table delete format is supported starting from MySQL 4.0.0. The second multi-table delete format is supported starting from MySQL 4.0.2.
The idea is that only matching rows from the tables listed
before the FROM
or before the USING
clause are
deleted. The effect is that you can delete rows from many tables at the
same time and also have additional tables that are used for searching.
The .*
after the table names is there just to be compatible with
Access
:
DELETE t1,t2 FROM t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id or DELETE FROM t1,t2 USING t1,t2,t3 WHERE t1.id=t2.id AND t2.id=t3.id
In the above case we delete matching rows just from tables t1
and
t2
.
If an ORDER BY
clause is used (available from MySQL 4.0.0), the rows
will be deleted in that order. This is really only useful in conjunction
with LIMIT
. For example:
DELETE FROM somelog WHERE user = 'jcole' ORDER BY timestamp LIMIT 1
This will delete the oldest entry (by timestamp
) where the row matches
the WHERE
clause.
The MySQL-specific LIMIT row_count
option to DELETE
tells
the server the maximum number of rows to be deleted before control is
returned to the client. This can be used to ensure that a specific
DELETE
command doesn't take too much time. You can simply repeat
the DELETE
command until the number of affected rows is less than
the LIMIT
value.
From MySQL 4.0, you can specify multiple tables in the DELETE
statement to delete rows from one or more tables depending on a particular
condition in multiple tables. However, you can not use ORDER BY
or LIMIT
in a multi-table DELETE
.
Posted by Javi Legido on Friday January 17 2003, @1:45pm | [Delete] [Edit] |
In these section you don't say nothing about the parent - child restrictions (on InnoDB tables), because you cannot delete a parent row only. You have to delete the parent, and child row
Posted by jeppe on Tuesday February 4 2003, @8:23am | [Delete] [Edit] |
When you delete a large portion of a MyISAM table, it may be necessary to run an optimize table job afterwards. When the data file becomes fragmented, or when the key distribution data comes out of sync with reality, then you will see large performance drops. Also, disk space will not be freed until you've run optimize.
These are not really bugs, but limitations that you should be aware of when you start deleting large amounts of data from your tables.