Schema changes – what’s new in MySQL 5.6?

MySQL 5.6Among many of the improvements you can enjoy in MySQL 5.6, there is one that addresses a huge operational problem that most DBAs and System Administrators encounter in their life: schema changes.

While it is usually not a problem for small tables or those in early stages of product life cycle, schema changes become a huge pain once your tables get a significant amount of data. Planning for maintenance is becoming more and more difficult, and your worldwide users want the service to be up and running 24/7, while on the other hand, your developers desire to introduce schema changes every week.


But what is the real problem here? Let me illustrate very typical case:

What you see above is how changing table’s structure works in MySQL in all pre-5.6 versions. Normally the example INSERT statement is done in matter of microseconds. But once a DBA runs this ALTER TABLE (session1), the application (session2) has to wait for the ALTER to complete before INSERT and other DML statements can succeed. As a result, application will stall on writes to this table until ALTER TABLE completes.


There are many less or more complicated approaches to the ALTER TABLE problem in MySQL, starting from just well planned downtime window, through master/slave switching techniques, ending on using advanced tools that let you do the change in less possible intrusive way. These tools are out there for years, yet it appears that still many MySQL users are not aware of them. Let me just name here pt-online-schema-change from Percona Toolkit, oak-online-alter-table from Openark Kit or Facebook OSC.


Historically, MySQL had to perform full table copy for all DDL (Data Definition Language) operations, while you could not write to a table being altered during the process. This problem is even more painful when awaiting writes can also block following reads.

An important, though small step forward was made for InnoDB storage engine since new InnoDB version (aka InnoDB plugin) was introduced for MySQL 5.1. Since then, you can create and drop indexes without copying the whole table contents. So at least the operation that is practised very often for query optimizations, can be done much much quicker.

Next significant improvement (or perhaps I should say fix) in DDL operations area was introduced in MySQL 5.5 as Metadata Locking. Basically from now on schema changes are working properly and consistent with transactions. You will find this explained in details here.

ONLINE(!) DDL in MySQL 5.6

Fortunately, this is not where so much desired evolution in this area has stopped! With MySQL 5.6, this time a huge step forward was made: from now on most of the ALTER types won’t block writes to a table that is being changed!

Another improvement is that in addition to existing instant ALTER implementations (like change default value for a column), now you can perform also following operations without the need of full table copy:

  • Change auto-increment value for a column
  • Rename a column (if data type remains the same)*
  • Add/Drop a foreign key constraint

As said before though, the main improvement in MySQL 5.6 is that during the ALTER operation a table being changed can still be fully accessible by clients, so both reads and writes (with few exceptions) are allowed! Complete statement matrix can be found here.

Let’s see some examples in practice

Example 1 – reset auto-increment value for a column

It can happen that wrong explicit insert sets the value for an auto-increment column higher then necessary. It may be even close to the data type limit and we want to make the table using lower values back again. We realize that and delete that high value row, but…

Not possible since the table has next AUTO_INCREMENT=2000002. So this alter is our only help:

Finally, this operation in MySQL 5.6 is instant! In previous MySQL versions such ALTER causes full table rewrite and blocks the table for writes for the whole process time. In version 5.5.31 the same ALTER on the same hardware looks like that:

Example 2 – DROP COLUMN

During the ALTER is in progress:

After the ALTER finished:

Great! Drop table was non-blocking, we can use the table without interruption.


Original column definition was:
rev_deleted tinyint(1) unsigned NOT NULL DEFAULT '0',

(The same column rename in MySQL 5.5 or earlier copies the whole table.)

But let’s try another column:
rev_timestamp char(14) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL DEFAULT '',

What the heck?

Hmm, let’s try another one:
rev_comment tinyblob NOT NULL,

So, by the way of writing this blog post I identified a new bug and reported it here:
In short, Online DDL does not work as expected when you rename a column of binary data type, but also for a char type with binary collation. The bug not only leads to full table copy but also blocks a table for writes.


In case you are not sure if an ALTER TABLE will copy and/or block the table, and you want to make sure your DDL statement won’t cause such problems, you can add new alter specifications to the statement: ALGORITHM and LOCK.

As we can see full table rebuild still needs locking.

So, ALGORITHM=COPY and LOCK=NONE are mutually exclusive.

Data type change of a column is both locking and makes full table copy.

Above example is pretty interesting as the new method is used, so no full table copy takes place, however whole operation is still as much expensive as the old way. This is because significant data reorganization is needed inside the existing ibd tablespace.

ALGORITHM and LOCK options allow you also to force using old method with full table copy by adding ALGORITHM=COPY or protect a table from writes with LOCK=SHARED. The same effect can be achieved with SET old_alter_table=1 before the ALTER.


I would like to mention that MySQL 5.6 offers new monitoring tools that we can use to see more details also about ongoing ALTERs.

This is how it looks like during the ALTER with adding a column is in progress:

To enable those counters, simply do:


I would not say that. Although schema changes are now a lot more friendly, but there seems to be still a room for improvement in terms of becoming even more “online”. And there is another aspect – we can’t really control the way online DDL is done in terms of server I/O load and replication. It is often the case when full table rewrite would generate enough high disk utilization to cause performance problems. Yet we cannot do anything about this in MySQL’s Online DDL – it will copy a table with full available speed no matter if it can saturate I/O throughput or not. Here the tools like pt-online-schema-change have this big advantage where it divides table copy into chunks and checks automatically a given status variable if there is not too high load on the server, and pauses data copy process if so.

When we speak about replication – with Online DDL each ALTER is a single operation, so after the master finishes it, it gets replicated to slaves. This will cause replication lag for the time slave has to apply long ALTER, as well as increased I/O activity on all slaves at the same time. Also in this regard pt-online-schema-change chunk copy model has huge advantage – schema change is replicated to the slaves and the tool will check how much slaves are lagged hence pause the copy process in case the lag is too big. Also the data chunks are automatically adjusted to fit within given time limit.

I was curious to compare time required for the same ALTER with ONLINE DDL versus pt-online-schema-change:


pt-online-schema-change wins here clearly, but it’s just one simple example out of many possible scenarios!


The fact that a table is ready for writes during Online DDL in progress, does not mean it will be performed at the same speed.

I tried a simple sysbench test to compare overall throughput of the MySQL server when the server is idle versus when ONLINE ALTER is in progress. Before the test I warmed up InnoDB buffers and ran sysbench test several times. All data for sysbench table fit in memory.

Then I started ALTER statement (for an unrelated table):

And just after that, the same sysbench command:

Below we can see concurrent threads:

To be clear, sysbench was started after ALTER, and finished before ALTER was done.

Result? On idle MySQL instance sysbench test score is around 270 transactions per second with minimal variation between many the same tests.
While Online DDL of unrelated table is in progress, the same test scored with average 110 transactions per second. Also minimal variation between many the same tests.

In next test, I altered the sbtest table – the same which is used by sysbench test, hence additional overhead of recording all the changes to that table.

Again, sysbench finished before the ALTER, and now the score was 90 transactions per second.
Note though this was only a very simple test of one example use case.


At the end I’d like to mention bugs regarding online DDL that in my opinion are important to be aware of. Fortunately there are not many of them. Following were active as of version 5.6.12: – in some circumstances statements needing table copy (like add column) create temporary table in tmpdir instead of the database directory – Replication is not crash safe with DDL statements – the bug around column rename, I just reported and mentioned above


I think schema changes in MySQL 5.6 are really less painful out of the box, plus we can still choose external tools if needed. Having said that, MySQL operators are in much better shape now. It is really good to see MySQL evolution is continued in right direction.

Share this post

Comments (13)

  • Alexander Zaitsev

    You probably know, that TokuDB supports hot schema changes and hot index creation since v5.0 (2011). I never tested how it workw, since we were off TokuDB by that time. But I suppose it should work, since that was one of the most desired features from multiple TokuDB customers by that time (TokuDB is for OLAP, OLAP means huge tables).

    July 5, 2013 at 10:55 am
  • Fernando Mattera

    Has TokuDB hot backups?

    July 5, 2013 at 12:09 pm
  • Przemysław Malkowski

    Alexander: yes, though TokuDB became Open Source this year. It might be a good subject for a next blog post.

    Fernando: Tokutek offers Hot Backup tool for TokuDB in it’s Enterprise Edition.

    July 6, 2013 at 3:51 am
  • paul

    by looking at the github repo for tokudb. it seems to support hot backups in the community edition but requires an application to be created / modified in order to use it.

    July 6, 2013 at 3:27 pm
  • Peter Zaitsev

    I wonder considering TokuDB is more light on DiskIO than traditional storage engines like Innodb would LVM and other snapshot based backups be working choice in more circumstances ?

    July 8, 2013 at 10:34 am
  • kim

    Is OPTIMIZE TABLE xxx; now online as well? OPTIMIZE used to map to an ALTER table and no writes could be done on the table while the optimize took place (to bring the optimizer stats up to date) for that table — a problem on large active tables.


    July 17, 2013 at 6:14 am
  • Przemysław Malkowski

    Kim: the problem is that there is no real “optimize table” feature for InnoDB, full table rebuild always happen. And it’s mapped to ALTER as you mentioned, so it’s the same as ALTER TABLE foo ENGINE=InnoDB. In the example #4 you can see this operation is locking.
    Optimize works totally different for MyISAM, but still the operation locks a table.

    However, I should mention, that you can do ALTER TABLE foo ENGINE=InnoDB in non-locking manner by just using pt-online-schema-change tool. And it works for all MySQL versions.

    July 17, 2013 at 6:37 am
  • Fernando Mattera


    I noticed about hotbackup in enterprise edition, but I didn’t found documentation. It’s so darl…

    July 17, 2013 at 9:30 am
  • Fernando Mattera

    “dark” I mean

    July 17, 2013 at 9:31 am
  • teo

    “from now on [5.6] most of the ALTER types won’t block writes to a table that is being changed!”

    That is BULLSHIT, unless in “most of the ALTER types” you don’t include adding columns. An ALTER operation as simple as adding a column in MySQL 5.6 will block all writes until the alter is finished, and there’s no way to avoid that.

    June 7, 2016 at 1:19 pm
  • Przemysław Malkowski

    @teo, Have you read the official documentation about which ALTER types allow concurrent DML? Limitations for adding columns are clearly stated and if you encountered another condition under which writes are blocked, you should IMHO report a bug.

    June 7, 2016 at 4:48 pm
  • teo

    @Przemysław Yes, I read the documentation; the documentation is clear and correct, your article isn’t so much, that’s my point. In the article you state that “most of the ALTER types won’t block writes to a table”. While “most” is a vague concept and you may argue that your statement, literally taken, is true (there are probably more ALTER statements that don’t block table writes than the ones which do), I would suggest to at least add a caveat that adding a column is NOT among those. Adding a column is a very common and very basic ALTER operation (indeed it seems pathetic to me that in the 21st century MySQL is still unable to do that without blocking writes on the whole table for the whole duration of the alter operation): so, if you state that “most” ALTER statements won’t block writes, I think most readers would assume that if adding a column was an exception, you would mention it.

    June 7, 2016 at 5:07 pm
  • honeybee

    @Przemyslaw, I think your article is great and I don’t appreciate people nit-picking.

    April 24, 2017 at 4:46 pm

Comments are closed.

Use Percona's Technical Forum to ask any follow-up questions on this blog topic.