5.6的online ddl

下午在更改一个表结构的时候，将其中的一个字段类型从varchar（30） 变更到varchar(512) 发现了上面tmp table的现象，而且造成很多元数据锁等待。不是说5.6支持online ddl 不需要create temp table的么?

在增加表字段的时候 ，出现的一直是altering table

上图分别是增加字段，将字段长度由30改为512，由30改为50时候的profile。从frofile中也可以看出来，修改变长字段长度、修改字段类型等会创建临时表，修改字段名，增加字段、drop字段、增加索引、drop索引 等不会创建临时表，采用的是in-place的方式。

查看文档，以下因素都会影响online  ddl是否成功

? Whether there is any change to the physical representation of the table, or whether it purely a change to metadata that can be done without touching the table itself.
是否没有改变表的物理形式，或则是都只是单纯的改变表的元数据，这种可以不触及表自身去改！

? Whether the volume of data in the table stays the same, increases, or decreases.
是否表数据容量还是一样的还是增加了或则减少了！

? Whether a change in table data involves the clustered index, secondary indexes, or both.
是否表的改变影响到了聚集索引，二级索引或则都影响到了。

? Whether there are any foreign key relationships between the table being altered and some other table. The mechanics differ depending on whether the foreign_key_checks configuration option is enabled or disabled.
是都有外键存在于改变的表和其他的表中间，结构改变取决于 foreign_key_checks 是启用还是禁用的。

? Whether the table is partitioned. Partitioning clauses of ALTER TABLE are turned into low-level operations involving one or more tables, and those operations follow the regular rules for online DDL.
是否是分区表，分区键操作会被转变为更低级别的涉及到一个或多个表的操作，这些操作遵循在线定义的一般规则

? Whether the table data must be copied, whether the table can be reorganized “in-place”, or a combination of both.
是否表的数据必须被复制，是否表可以以in-place的方式重组

? Whether the table contains any auto-increment columns.
表是否有自增列

? What degree of locking is required, either by the nature of the underlying database operations, or a LOCK clause that you specify in the ALTER TABLE statement.
需要什么深度的锁。

实验发现，在drop colum 和add column的时候，对之前存储的数据只用改null标志位，其他都不用改动！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/30018455/viewspace-2124339/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/30018455/viewspace-2124339/