Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I'm running MySQL5.5 with Master/Slave replication (1 master, 2 slaves).

I have a process that runs once a week and truncate a specific table. The table is not large and only has a few thousands records.

For some reason, the TRUNCATE TABLE command takes really long time to execute (both on the master and on the slave). It takes about 400K ms to execute!! When it runs on the slave, it causes it to lag from the Master. After the TRUNCATE TABLE finishes, everything is back to normal.

I know that one of the slaves didn't receive any reads while performing the TRUNCATE TABLE since its a dedicated slave and the process that reads from that slave was down. Also, on this slave, it took the same amount of time to execute.

Here is the table structure: http://pastebin.com/qEQB4juR

Any thoughts on how I can speed up the TRUNCATE TABLE ?

share|improve this question
add comment

1 Answer

Using TRUNCATE TABLE on an InnoDB table requires a full table lock because TRUNCATE TABLE is DDL (Data Definition Language) not DML (Data Manipulation).

Doing DELETE FROM user_engagements; will not help because MVCC info is written to the undo logs in ibdata1, and that can hold up the table from being emptied. If any uncommitted transactions are holding onto user_engagements, that could potentially hold up a TRUNCATE TABLE as well.

You could rename the table so that it is immediately available

SET FOREIGN_KEY_CHECKS = 0;
CREATE TABLE user_engagements_new LIKE user_engagements;
ALTER TABLE user_engagements RENAME user_engagements_zap;
ALTER TABLE user_engagements_new RENAME user_engagements;
DROP TABLE user_engagements_zap;
SET FOREIGN_KEY_CHECKS = 1;

This should replicate quickly except for the last statement.

Give it a Try !!!

If you have MySQL 5.1.16+, TRUNCATE TABLE requires DROP privilege. My answer performs what TRUNCATE TABLE now does.

If you have MySQL 5.1.15 and back, you need DELETE privilege, which my answer covers.

share|improve this answer
1  
Isn't the rename subject to a table lock just as the truncate? –  a_horse_with_no_name Jul 9 '12 at 22:34
    
@a_horse_with_no_name Good point. I updated my answered accordingly. –  RolandoMySQLDBA Jul 9 '12 at 22:48
    
I would use a multi-part RENAME TABLE statement instead of ALTER TABLE in order to make the rename atomic: RENAME TABLE user_engagements TO user_engagements_zap, user_engagements_new TO user_engagements; Another consideration is that DROP TABLE causes the LRU_mutex to be locked while the LRU list is scanned and each entry is removed - this will stall your server. Percona Server has innodb_lazy_drop_table to help with this, but DROP TABLE still can take a long time on ext filesystems. –  Aaron Brown Jul 10 '12 at 2:01
    
could it be that the truncate table is taking a lot of time because of the partitions on the table (1000), I can remove them if that will lead to the solution? –  Ran Jul 10 '12 at 6:56
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.