MySQL5.5加主键锁读问题_MySQL

MySQL5.5加主键锁读问题

背景

有同学讨论到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的。