起因
前一段时间,公司新切换到新的云服务提供商,切换过程还算顺利,新接到需求优化查询效率(详细优化过程查看上篇文章),需要新增索引,为了避免不必要的问题(害怕数据库服务是经过魔改的),向服务商咨询了新建索引是否支持Online DDL,然后发生了一次友好的技术交流
交流过程
Round 1
- 我:新增索引支持online ddl吗?会不会锁表?
- 服务商:版本是多少?
- 我:5.7
- 服务商:8.0的话就可以
- 我:MySQL 5.7的话只有等待MDL锁才会锁表,复制数据是不会的,你们是有做格外修改?
- 服务商:我们研发说是会锁表的哦,5.6 & 5.7并不是真正的online ddl操作,不是原子性的,8.0才真正实现
- 服务商:你可以参考一下这个文档https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl.html
Round 2
看到他发出MySQL官方文档,我立马就不困了,那就是说是根正苗红的MySQL咯,这我熟啊,让我参考文档是吧,那就按文档说话,开始附上文档截图交流
- 我:新增索引的话,文档上是可以不重建表,并发DML的
- Rebuilds Table:是否需要重建表
- Permits Concurrent DML:是否允许并发DDL
注意:这里只讨论新增索引,其他DDL请查阅支持文档
- 服务商:
如果存在表的调用,比如增删改查,对表做ddl操作,这个是会存在mdl锁的
锁等待时多个进程而不是只看当前的这一个线程的操作,一个线程同时间操作一个表,不管是加表锁,行锁还是元数据锁都是不影响的
对于服务的影响肯定是ddl操作期间的操作阻塞了服务对这个表的其他操作
- 我:MySQL Online DDL会加语句准备和提交阶段短时间的加MDL写锁,等待写锁及持有写锁的过程会阻塞其他DML操作,并不会阻塞整个DDL过程
Online DDL分为三个阶段
- 初始化:会加共享锁
- 执行:可能会在语句准备期间短暂使用独占锁
- 提交表定义:短时间升级为独占锁,用于提交表定义
所以服务商说:“ddl操作期间的操作阻塞了服务对这个表的其他操作”这是不正确的。
不过必须注意该表是否参与长事务,不然在等待长事务释放锁的过程中,会阻塞后面的DML、DQL
- 服务商:文档上还有参数的配置,在线ddl的过程和参数配置也是有很大关系的
- 我:默认不指定会按MySQL能使用的online方式去执行
不指定ALGORITHM,会优先使用 INPLACE,不支持才会降级为 COPY
不指定LOCK,也会尽量不加锁执行
总结
当然,最后创建索引是在业务低峰期执行的,Online DDL正如我上面所说的,并不是完全不加锁,可以的话当然选择在最佳的时间执行,避免对上线业务有影响