MySQL5.7 Online DDL

本文详细介绍了MySQL中ALTER TABLE操作的工作原理,包括何时创建临时副本,哪些操作不需要副本以及对读写的影响。对于在线DDL操作,讨论了重命名列、改变VARCHAR长度、主键修改等场景,并提供了判断操作是否在线的依据。同时,提出了评估大表DDL效率的方法,以及如何通过观察'rows affected'来确定操作类型。最后,建议通过分析性能和信息表来深入理解DDL操作对系统资源的影响。
摘要由CSDN通过智能技术生成

1. ALter table (5.7)

    一般情况下,alter table  都会对原有的表做一个临时的副本拷贝,然后将所做的该表应用到副本,之后再将原表删除,rename 副本。在这个过程中,原表对外是可读的;但是对该表DML会被堵塞,直到alter 完成。

    The exception referred to earlier is that ALTER TABLE blocks reads (not just writes) at the point where

it is ready to install a new version of the table .frm file, discard the old file, and clear outdated table

structures from the table and table definition caches. At this point, it must acquire an exclusive lock. To

do so, it waits for current readers to finish, and blocks new reads (and writes). 

在 alter table读取块,安装新建的.frm 。丢弃就得文件和数据时,会加排它锁。

下面操作一般不需要创建临时副本:

    1)ALTER TABLE tbl_name RENAME TO new_tbl_name without any other options ;

    2)只改变表的元数据而不改动数据时 :

        (1)列的重命名;

        (2)改变列的默认值;

        (3)对ENUM和SET列在成员列表最后添加列表(但是向具有8个成员的SET列添加成员会将所需的存储空间每个值从1个字节更改为2个字节;  在列表中间添加成员会导致现有成员重新编号,这些需要一个表副本。)

     3)表空间的丢弃和导入;

     4)索引重命名,添加和删除索引(for innodb and NDB)

2 Summary of Online Status for DDL Operations

(1)重命名列

    只改变列名而不改变列的属性,可以进行在线操作;

    对于修改外键所在的列,不能使用ALGORITHM=COPY选项。

(2)改变VARCHAR 列的字符长度

    若原VARCHAR列定义的长度在0-255范围内,修改后也在该范围则可以使用ALGORITHM=INPLACE;

    若原VARCHAR列定义的长度在256以上,修改后也在该范围则也可以使用ALGORITHM=INPLACE;

    但是若从小于256范围变为大于256的范围,或者varchar列长度由大变小,则会进行表的副本拷贝。

  (3)下列操作,虽然进行表的副本拷贝但是依然支持DML

    • Adding, dropping, or reordering columns.

    • Adding or dropping a primary key.

    • Changing the ROW_FORMAT or KEY_BLOCK_SIZE properties for a table.

    • Changing the nullable status for a column.

    • OPTIMIZE TABLE

    • Rebuilding a table with the FORCE option

    • Rebuilding a table using a “null” ALTER TABLE ... ENGINE=INNODB statement

  注意:若需要进行表的副本拷贝,则表副本会临时在参数tmpdir 指定的路径下。任何DDL语句都会等待当前的事务结束才会开始执行,因为在DDL执行伊始和最后都短暂的加排他锁。

  虽然对于主键的修改需要做表的副本拷贝,但是使用ALGORITHM=INPLACE是被允许的,且比ALGORITHM=COPY的效率要高。因为ALGORITHM=INPLACE 不需要记录相应的undo和redo日志,二级索引已经存储好,可以顺序load,由于没有随机的二级索引插入所以也没使用到change buffer。

  (4)DDL操作是执行了 inplace 还是copy ,最直观的表现就是查看操作完成后的“rows affected”,如下:

(5) 对于一个大表的操作,需要确认相应DDL执行的效率:

    1). Clone the table structure.

    2). Populate the cloned table with a tiny amount of data.

    3). Run the DDL operation on the cloned table.

    4). Check whether the “rows affected” value is zero or not. A non-zero value means the operation willrequire rebuilding the entire table, which might require special planning. For example, you might do the DDL operation during a period of scheduled downtime, or on each replication slave server one at a time.

For a deeper understanding of the reduction in MySQL processing, examine the performance_schema and INFORMATION_SCHEMA tables related to InnoDB before and after DDL operations, to see the number of physical reads, writes, memory allocations, and so on.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值