企业网站做优化哈尔滨电话本黄页
目录
一、Mysql5.6-8.0在线DDL操作是否锁表介绍
time:2025/05/07
Author:skatexg
重要
所有的DDL操作均建议在业务低峰期进行，以避免对业务产生影响。
一、Mysql5.6-8.0在线DDL操作是否锁表介绍
| 操作 | 是否需要重建表(影响性能) | MySQL5.6是否允许并发DML | MySQL5.7是否允许并发DML | MySQL8.0是否允许并发DML | 备注 |
| 创建普通索引 | 不需要 | 允许 | 允许 | 允许 | 无。 |
| 创建全文索引 | 不需要 | 不允许 | 不允许 | 不允许 | 第一个全文索引需要通过Copy Table的方式创建；其后的全文索引可以通过Inplace方式创建。 |
| 删除索引 | 不需要 | 允许 | 允许 | 允许 | 仅修改表元数据metadata。 |
| 优化表 | 需要 | 允许 | 允许 | 允许 | 如果表上创建有全文索引，则不支持algorithm=inplace选项。 |
| 设置列默认值 | 不需要 | 允许 | 允许 | 允许 | 仅修改表元数据metadata。 |
| 修改自增列值 | 不需要 | 允许 | 允许 | 允许 | 仅修改表元数据metadata。 |
| 添加外键约束 | 不需要 | 允许 | 允许 | 允许 | set foreign_key_checks=0; 来关闭 foreign_key_checks，避免拷贝表。 |
| 删除外键约束 | 不需要 | 允许 | 允许 | 允许 | foreign_key_checks选项开启或者关闭都可以。 |
| 重命名列 | 不需要 | 允许 | 允许 | 允许 | 如果仅仅修改字段名称，而不要修改字段类型，是支持并发DML操作的。 |
| 添加列 | 需要 （mysql8.0不需要） | 允许 | 允许 | 允许 | 在添加auto_increment自增列时，是不允许并发 DML 操作的。 尽管支持Algorithm=INPLACE ，但因为数据实质上需要重新组织，因此操作的开销高昂。 |
| 删除列 | 需要 | 允许 | 允许 | 允许 | 尽管支持Algorithm=INPLACE ，但因为数据实质上需要重新组织，因此操作的开销高昂。 |
| 修改各列顺序 | 需要 | 允许 | 允许 | 允许 | 尽管支持Algorithm=INPLACE ，但因为数据实质上需要重新组织，因此操作的开销高昂。 |
| 修改Row_Format属性 | 需要 | 允许 | 允许 | 允许 | 尽管支持Algorithm=INPLACE ，但因为数据实质上需要重新组织，因此操作的开销高昂。 |
| 设置列为空值Null | 需要 | 允许 | 允许 | 允许 | 尽管支持Algorithm=INPLACE ，但因为数据实质上需要重新组织，因此操作的开销高昂。 |
| 设置列不为空值NOT Null | 需要 | 允许 | 允许 | 允许 | 该操作需要将SQL_MODE 参数设置为STRICT_ALL_TABLES或STRICT_TRANS_TABLES才能成功。如果列值中包含空值（NULL），则该DDL 操作会失败。 尽管支持Algorithm=INPLACE ，但因为数据实质上需要重新组织，因此操作的开销高昂。 |
| 修改列的数据类型 | 需要 | 不允许 | 不允许 | 不允许 | 无。 |
| 扩展VARCHAR列大小 | 需要 （mysql8.0不需要） | 不允许 | 允许 | 允许 | 无 |
| 添加主键 | 需要 | 允许 | 允许 | 允许 | 尽管支持Algorithm=INPLACE ，但因为数据实质上需要重新组织，因此操作的开销高昂。 如果涉及的列需要转换为NOT NULL，则不支持Algorithm=INPLACE。 |
| 删除主键并添加新主键 | 需要 | 允许 | 允许 | 允许 | 仅当在同一个Alter Table语句中（删除主键的DDL语句）添加新主键才支持Algorithm=INPLACE。 因为数据实质上需要重新组织，因此操作的开销高昂。 |
| 删除主键 | 需要 | 不允许 | 不允许 | 不允许 | 无。 |
| Convert character set | 需要 | 不允许 | 不允许 | 不允许 | 如果新的字符集编码不同，需要重建表。 |
| 重建表 alter table ... engine=innodb | 需要 | 允许 | 允许 | 允许 | 如果表上有全文索引，则不支持Algorithm=Inplace选项。 |
| 修改表注释 | 不需要 | 允许 | 允许 | 允许 | 无。 |
- 从MySQL5.6升级到MySQL5.7降低阻塞概率，并提升性能
- MySQL官方文档请参见Online DDL 概览
- MySQL的DDL不同变更模式的对比（如下）
| 对比维度 | INSTANT | INPLACE | COPY TABLE |
| 定义 | 仅更新数据字典（元数据），不涉及表数据的物理修改或移动，操作耗时极短（毫秒级）。 | 在原表位置直接修改表结构，可能重建索引或重组数据，但不复制全表数据。 | 创建临时表（目标结构），将原表数据全量复制到临时表，再替换原表。 |
| 实现原理 | 仅修改元数据，不接触实际数据。 | 原表直接操作，可能重建索引 / 重组数据。 | 全量复制数据到临时表，再替换原表。 |
| 适用场景 | 元数据变更（如添加 nullable 列、改默认值）。 | 结构变更（如改列类型、增删索引、重命名）。 | 复杂变更或旧版本兼容，需全量重建表。 |
| 性能 | 最优（毫秒级，几乎无影响）。 | 中等（依赖数据量，需部分 IO/CPU）。 | 最差（全量复制，耗时久、资源占用高）。 |
| 空间占用 | 几乎不占用额外空间。 | 少量临时空间（用于索引重建等）。 | 需约 1 倍原表空间（临时表存储）。 |
| 支持版本 | MySQL 8.0.12+ | MySQL 5.6+（随版本优化） | 所有版本（传统模式） |
| 锁与阻塞 | 仅短暂元数据锁，不阻塞读写。 | 可能加排他锁（DDL 期间锁表时间较短）。 | 锁表时间长（复制数据时阻塞写操作）。 |
| 数据影响 | 无数据移动或转换。 | 部分数据可能重组（如索引碎片整理）。 | 全量数据复制，可能涉及字符集转换等。 |
---end---