任何DDL操作,执行者都需要预先测试或者清晰了解这个操作会给数据库带来的影响是否是在业务期间数据库的可承受范围内,尤其是对大表的DDL操作中,需要密切留意服务器的IO,内存及CPU使用情况(每个DBA总有那么一段被大表的DDL语句坑到的血泪史)。

 



 

    如果转载,请注明博文来源: www.cnblogs.com/xinysu/   ,版权归 博客园 苏家小萝卜 所有。望各位支持!

  



回到顶部(go to top)

1 早期DDL实现原理(5.6.7之前 

    Innodb早期支持通过copy table跟inplace的方式来执行DDL语句,其原理如下:

  • copy table方式

    • 新建跟原表格一致的临时表,并在该临时表上执行DDL语句

    • 锁原表,不允许DML,允许查询

    • 逐行数据从原表拷贝到临时表中(这个过程是没有排序的)

    • 拷贝结束后,原表禁止读操作,也就是原表此时不提供读写服务

    • 进行rename操作,完成DDL过程

  • inplace方式(fast index creation,仅针对索引的创建跟删除)

    • 新建frm临时文件

    • 锁原表,不允许DML,允许查询

    • 按照聚集索引的顺序,查询数据,找到需要的索引列数据,排序后插入到新的索引页中

    • 原表禁止读操作,也就是原表此时不提供读写服务

    • 进行rename操作,替换frm文件,完成DDL过程

    inplace在copy table的基础上做了一个较大的改进,则是不需要copy整个表格,只需要在原来的ibd文件上,新建所需要的索引页,这个过程比copy table节约极大的IO