DELETE Statement executing  ALTER TABLE t TRUNCATE PARTITION (p0) ; in both cases, all rows in partition  p0  are dropped. PARTITION  can be used along with a  WHERE  condition, in which case the condition is tested only on rows in the listed partitions. For example,  DELETE FROM t PARTITION (p0) WHERE c < 5  deletes rows only from partition  p0  for which the condition  c < 5  is true; rows in any other partitions are not checked and thus not affected by the  DELETE . The  PARTITION  clause can also be used in multiple-table  DELETE  statements. You can use up to one such option per table named in the  FROM  option. For more information and examples, see Section 24.5, “Partition Selection” . If you delete the row containing the maximum value for an  AUTO_INCREMENT  column, the value is not reused for a  MyISAM  or  InnoDB  table. If you delete all rows in the table with  DELETE FROM  tbl_name (without a  WHERE  clause) in  autocommit  mode, the sequence starts over for all storage engines except InnoDB  and  MyISAM . There are some exceptions to this behavior for  InnoDB  tables, as discussed in Section 15.6.1.6, “AUTO_INCREMENT Handling in InnoDB” . For  MyISAM  tables, you can specify an  AUTO_INCREMENT  secondary column in a multiple-column key. In this case, reuse of values deleted from the top of the sequence occurs even for  MyISAM  tables. See Section 3.6.9, “Using AUTO_INCREMENT” . The  DELETE  statement supports the following modifiers: If the  DELETE  statement includes an  ORDER BY  clause, rows are deleted in the order specified by the clause. This is useful primarily in conjunction with  LIMIT . For example, the following statement finds rows matching the  WHERE  clause, sorts them by  timestamp_column , and deletes the first (oldest) one: DELETE FROM somelog WHERE user = ’jcole’ ORDER BY timestamp_column LIMIT 1; ORDER BY  also helps to delete rows in an order required to avoid referential integrity violations. If you are deleting many rows from a large table, you may exceed the lock table size for an  InnoDB  table. To avoid this problem, or simply to minimize the time that the table remains locked, the following strategy (which does not use  DELETE  at all) might be helpful: 2623 InnoDB Tables Order of Deletion Modifiers Auto-Increment Columns •If you specify the  LOW_PRIORITY  modifier, the server delays execution of the  DELETE  until no other clients are reading from the table. This affects only storage engines that use only table-level locking (such as  MyISAM ,  MEMORY , and  MERGE ). •For  MyISAM  tables, if you use the  QUICK  modifier, the storage engine does not merge index leaves during delete, which may speed up some kinds of delete operations. •The  IGNORE  modifier causes MySQL to ignore ignorable errors during the process of deleting rows. (Errors encountered during the parsing stage are processed in the usual manner.) Errors that are ignored due to the use of  IGNORE  are returned as warnings. For more information, see The Effect of IGNORE on Statement Execution.