Oracle 5.0 Reference Manual page 1082

statement or the
myisamchk
but is faster. See
myisamchk
"myisamchk — MyISAM Table-Maintenance
The modifier affects whether index leaves are merged for delete operations.
QUICK
most useful for applications where index values for deleted rows are replaced by similar index values
from rows inserted later. In this case, the holes left by deleted values are reused.
is not useful when deleted values lead to underfilled index blocks spanning a range of
DELETE QUICK
index values for which new inserts occur again. In this case, use of
the index that remains unreclaimed. Here is an example of such a scenario:
1. Create a table that contains an indexed
2. Insert many rows into the table. Each insert results in an index value that is added to the high end
of the index.
3. Delete a block of rows at the low end of the column range using
In this scenario, the index blocks associated with the deleted index values become underfilled but
are not merged with other index blocks due to the use of QUICK. They remain underfilled when new
inserts occur, because new rows do not have index values in the deleted range. Furthermore, they
remain underfilled even if you later use
values happen to lie in index blocks within or adjacent to the underfilled blocks. To reclaim unused
index space under these circumstances, use
If you are going to delete many rows from a table, it might be faster to use
TABLE. This rebuilds the index rather than performing many index block merge operations.
OPTIMIZE
The MySQL-specific
LIMIT row_count
rows to be deleted before control is returned to the client. This can be used to ensure that a given
statement does not take too much time. You can simply repeat the
DELETE
number of affected rows is less than the
If the statement includes an
DELETE
clause. This is useful primarily in conjunction with LIMIT. For example, the following statement finds
rows matching the
WHERE
one:
DELETE FROM somelog WHERE user = 'jcole'
ORDER BY timestamp_column LIMIT 1;
may also be useful in some cases to delete rows in an order required to avoid referential
ORDER BY
integrity violations.
If you are deleting many rows from a large table, you may exceed the lock table size for an
table. To avoid this problem, or simply to minimize the time that the table remains locked, the following
strategy (which does not use
1. Select the rows not to be deleted into an empty table that has the same structure as the original
table:
INSERT INTO t_copy SELECT * FROM t WHERE ... ;
2. Use
RENAME TABLE
the original name:
RENAME TABLE t TO t_old, t_copy TO t;
3. Drop the original table:
DROP TABLE t_old;
Syntax
DELETE
utility to reorganize tables.
Section 13.7.2.5,
Utility".
AUTO_INCREMENT
DELETE
OPTIMIZE
option to
LIMIT
ORDER BY
clause, sorts them by timestamp_column, and deletes the first (oldest)
at all) might be helpful:
DELETE
to atomically move the original table out of the way and rename the copy to
1062
OPTIMIZE TABLE
"OPTIMIZE TABLE Syntax", and
QUICK
column.
DELETE
without QUICK, unless some of the deleted index
TABLE.
tells the server the maximum number of
DELETE
value.
clause, rows are deleted in the order specified by the
is easier to use,
Section 4.6.3,
DELETE QUICK
can lead to wasted space in
QUICK.
followed by
DELETE QUICK
statement until the
DELETE
InnoDB
is