When you truncate a table
that is stored in a
.ibd file
of its own (because
innodb_file_per_table was enabled
when the table was created), and if the table is not referenced in
a FOREIGN KEY constraint, the table is dropped
and re-created in a new .ibd file. This
operation is much faster than deleting the rows one by one. The
operating system can reuse the disk space, in contrast to tables
within the InnoDB system
tablespace, where only InnoDB can use the space after they
are truncated. Physical
backups can also be smaller, without big blocks of unused
space in the middle of the system tablespace.
Previous versions of InnoDB would re-use the existing
.ibd file, thus releasing the space only to
InnoDB for storage management, but not to the operating system.
Note that when the table is truncated, the count of rows affected
by the TRUNCATE TABLE statement is an arbitrary
number.
If there is a referential constraint between two columns in the same table, that table can still be truncated using this fast technique.
If there are referential constraints between the table being
truncated and other tables, the truncate operation fails. This
is a change to the previous behavior, which would transform the
TRUNCATE operation to a
DELETE operation that removed all the rows
and triggered ON DELETE operations on
child tables.

User Comments
Add your own comment.