TRUNCATE is usually a fast operation (much faster than DELETE FROM). But sometimes it just hangs; I’ve has several such uncheerful events with InnoDB (Plugin) tables which were extensively written to. The TRUNCATE hanged; nothing else would work; minutes pass.
TRUNCATE on tables with no FOREIGN KEYs should act fast: it translate to dropping the table and creating a new one (and it all depends on the MySQL version, see the manual).
What’s faster than TRUNCATE, then? If you don’t have triggers nor FOREIGN KEYs, a RENAME TABLE can come to the rescue. Instead of:
TRUNCATE log_table
Do:
CREATE TABLE log_table_new LIKE log_table; RENAME TABLE log_table TO log_table_old, log_table_new TO log_table; DROP TABLE log_table_old;
I found this to work well for me. Do note that AUTO_INCREMENT values can be tricky here: the “new” table is created with an AUTO_INCREMENT value which is immediately taken in the “working” table. If you care about not using same AUTO_INCREMENT values, you can:
ALTER TABLE log_table_new AUTO_INCREMENT=some high enough value;
Just before renaming.
I do not have a good explanation as for why the RENAME TABLE succeeds to respond faster than TRUNCATE.
“I do not have a good explanation as for why the RENAME TABLE succeeds to respond faster than TRUNCATE.”
Try deleting a large file with ext3 versus renaming it. This will explain a lot of the problem 😉
Hi Morgan,
So simple… :D, thanks!
At least on two machines I have xfs for sure, though… So there’s still a small mystery…
Isn’t the table being dropped after renamed though? It should still have the same contention on the disk (if that was the original problem), as long as you are deleting the data.
@Darius,
Not a problem, since the dropped table has no contention: no one is writing to it.
shlomi: The table renamed & dropped still has some contention issues (lock_open mutex will be held), but your trick is still useful for emptying a table and being able to use it again.