MySQL字段长度修改 锁表情况分析

前言

最近发现有一个780w左右的表的某个字段长度设置不合理，导致数据无法插入 ， 于是计划修改长度。 担心会锁表阻塞业务所以选择晚上执行修改， 结果在晚上发现这个修改是秒生效， 并没有阻塞数据库，于是分析下原因。

字段content修改前类型是varchar(255) 字符编码是utf8mb4。 修改成varchar(2048)

MySQL的行存储格式

mysql的每行数据的默认存储格式是dynamic， 但是dynamic格式和compact格式差异不大， 本文以 compact的行格式说明问题， compact的行格式如下：

头部有一个变长字段列表， 其中存储的是这一行中变长字段的长度。

比如我content字段之前是varchar(255). 而utf8mb4每个汉字4个字节表示， content存满后的长度是1020字节， 在头部就需要存储一个数字1020， 所以头部中有两个字节是用来表示content的长度的。

现在我把长度改成了varchar(2048), 修改后存满需要8192字节， 还是只需要两个字节来表示这个长度， 因此每一行记录的变长字段部分不需要修改。

总结

1. mysql的compact的行格式中每行头部会开辟对应的空间来存储变长字段长度值。
2. 如果修改变长字段的长度 导致行头部已有的空间不够表达字段长度了， 就会修改每一行的头部
3. 在修改每一行的头部的时候就会锁住全表。
4. 如果修改的字段的长度， 头部现有的空间依旧可以满足变长字段长度的表示需要， 则不会修改每一行数据， 就不会锁表了。