Spec-Zone .ru
спецификации, руководства, описания, API
|
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.
MySQL 5.1 and earlier 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 foreign key constraint between two columns in the same table, that table can still be truncated using this fast technique.
If there are foreign key 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.