有同学讨论到MySQL 5.5下给大表加主键时会锁住读的问题，怀疑与fast index creation有关，这里简单说明下。
对照现象
为了说明这个问题的原因，有兴趣的同学可以做对比实验。
1) 在给InnoDB表创建主键期间，会锁住该表上的读数据
2) 但是同样的表执行删除主键期间，不会锁住该表上的读操作
----这说明与是否fast index creation无关，因为这两个操作在数据层面的行为应该是类似的，实际上，创建/删除主键都必须copy data。
3) 在创建主键期间，会锁住该表上执行的show create table
----用1、3的现象可以猜测出，实际上与meta data lock有关。
关于meta data lock(MDL)
MySQL 5.5中引入了MDL，当需要访问、修改表结构时，都需要对meta data加锁（读或写）。比如，当一个线程需要修改表结构的任意一部分时，此时需要阻塞对表结构的访问，当然也需要阻塞对数据行的访问。
加主键流程
当对一个表作加主键操作时，大致流程如下
1) MDL加写锁
2) 操作数据，最耗时部分，注意需要copy data，因此流程上是
a)创建一个临时表A，表A定义为修改后的表结构
b)从原表读取数据插入表A
c)删除原表，将表A重命名为原表名
3) MDL释放写锁
从这个流程可以看到，在最耗时的部分，meta data是被一个X锁保护的。因此在此期间，show create table或者select data都是会被阻塞。
这解释了上面的1) 3)。
删除主键流程
1) MDL加读锁
2) 操作数据，最耗时部分
a) 创建一个临时表A，表A定义为修改后的表结构
b) 从原表读取数据插入表A
3) MDL将读锁升级为写锁
c) 删除原表，将表A重命名为原表名
4) MDL释放写锁
这个在最耗时的数据操作部分，加的是MDL的读锁，这样不会影响访问原表的表结构或数据（当然要做更新是不行的）。而最后升级为写锁的时间，只是做重命名表的操作，阻塞的时间就很短。
结论
1) 显然第二个流程更合理
2) 这个可以认为是MySQL一个可改进的点，并且在5.6下已经改进
3) 这个问题与是copy data还是inplace方式执行DDL无关，实际上由于InnoDB的聚集索引组织结构，增、删主键都是必须得copy data的。
==========更新====
有同学问说为什么在5.5 set old_alter_table=on;之后是不会阻塞读的？ 因为打开old_alter_table之后，MySQL认为这次无论如何是要copy data的，所以锁用的是“删除主键流程”的策略。
实际上无论old_alter_table是否打开，对主键操作都是必须copy data的，5.6的改进就是基于这个判断。
