文章目录
- alter锁表问题
- 批量删除导致IO出现瓶颈
alter锁表问题
Mysql5.6版本之前 更新步骤
- 对原始表加写锁
- 按照原始表和执⾏语句的定义,重新定义⼀个空的临时表。
- 对临时表进⾏添加索引(如果有)。
- 再将原始表中的数据逐条Copy到临时表中。
- 当原始表中的所有记录都被Copy临时表后,将原始表进⾏删除。再将临时表命名为原始表表名。
- 这样的话整个DDL过程的就是全程锁表的。
Mysql5.6版本之后 更新步骤
- 对原始表加写锁
- 按照原始表和执⾏语句的定义,重新定义⼀个空的临时表。并申请rowlog的空间。
- 拷贝原表数据到临时表,此时的表数据修改操作(增删改)都会存放在rowlog中。此时该表客户端可以进⾏操作的。
- 原始表数据全部拷贝完成后,会将rowlog中的改动全部同步到临时表,这个过程客户端是不能操作的(insert 会报
Duplicate entry 'XXX' for key 'XXX'
)。 - 当原始表中的所有记录都被Copy临时表,并且Copy期间客户端的所有增删改操作都同步到临时表。再将临时表命名为原始表表名。
总结:ALTER TABLE 加字段会加锁。只是Mysql5.6版本之后新增了ONLINE DDL的功能,可以使该表不能使⽤的时间⼤⼤缩短。
注意:ALTER TABLE 加字段的时候。如果该表的数据量⾮常⼤。不要设置default值。 ⽐如,当前有2000万以上数据量的表。如果加字段加了default值。Mysql会执⾏在执⾏Online DDL之后,对整个表的数据进⾏更新默认值的操作,即UPDATE table_name SET new_col = [默认值] WHERE TRUE
,这样就相当于是更新了2000w+的数据,⽽且是在同⼀个事务⾥。也就是说这个事务会把整个表都锁住,直到所有的数据记录都更新完默认值以后,才会提交。这个时间⾮常长,⽽且由于会锁全表的记录,所以该表不可⽤的时间会⾮常长。
笔者实验过16核,32G,Mysql默认配置。500w的数据量加⼀个字段。不加default值,整个DDL更新过程是66秒。⽽且整个更新过程,该表的查询、修改、新增操作都是可⽤的。⼏乎对该表的可⽤性没有任何影响。加default值,整个DDL更新过程是213秒。经过测试,⼤约在100秒之后,该表的查询、修改、新增操作都会陷⼊等待状态。
批量删除导致IO出现瓶颈
背景:线上临时表积压数据过多,虽然有索引和数据归档,但是每日新增数据量>删除&归档数量,导致整体数据操作效率变慢。所以提交数据库删除工单,结果导致线上数据库半个小时内整个数据库集群链接不可用。
原因:数据表有大字段,根据ID一次性删除时数据库IO出现瓶颈。
解决办法:有大字段时,建议分批次删除,一次只删除50万~100万数据。