MySQL Forums :: Performance :: Improve performance when altering huge tables


Advanced Search

Re: Improve performance when altering huge tables
Posted by: Rick James ()
Date: April 05, 2016 02:59PM

You need 5.6, which has ALTER .. ALGORITHM=INPLACE .

An alternative for 5.5 is to use Percona's pt-online-schema-change. It does require that the table be InnoDB and have no TRIGGERs, since it will add triggers.

Another alternative is to create a "parallel" table ("vertical partitioning") and put the new columns, plus the original PRIMARY KEY column(s), in it. Then use JOIN to get the new columns. A bonus: If the new columns don't exist for all rows, leave out records in the new table (and use LEFT JOIN to get NULL).

The two settings should not have anything to do with this ALTER. And it is dangerous to leave them set to such high values because complex SELECTs use them and could blow out RAM.

ALTER TABLE (in 5.5 and before) will copy the table over and rebuild all the indexes. This is akin to CREATE TABLE + INSERT..SELECT + RENAME.

It is best to have innodb_buffer_pool_size set to about 70% of available RAM. That is where InnoDB does its work, not "tmp table", nor MEMORY (max_heap_table_size).

"long time was due to writing a temporary table to disk" -- did PROCESSLIST say something like that? If so, what was the exact text?

Options: ReplyQuote


Subject Views Written By Posted
Improve performance when altering huge tables 711 Davide Cicuta 04/04/2016 07:24AM
Re: Improve performance when altering huge tables 418 Rick James 04/05/2016 02:59PM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.