MySQL在线DDL通过INPLACE、COPY和INSTANT算法实现表结构变更，其中INSTANT（8.0.12+）仅修改元数据，秒级完成；添加索引和字段等操作在支持INPLACE或INSTANT时可并发DML，但修改字段类型常需重建表并阻塞写入；为保障生产环境稳定，应评估变更类型、选择低峰期执行，并优先使用原生ALTER处理小变更，大表则借助gh-ost等工具实现零停机，全程需监控资源与锁状态。
MySQL在线DDL（Data Definition Language）操作允许在不阻塞读写的情况下修改表结构，提升数据库可用性。随着MySQL版本迭代，尤其是从5.6引入Online DDL，到5.7和8.0的优化，大部分ALTER操作已支持“在线”执行。理解其机制与合理制定变更策略，对生产环境至关重要。
MySQL在线DDL的核心机制
MySQL通过InnoDB的“原地修改”（in-place）和“重建表”（rebuild）机制实现在线DDL。关键特性包括：
- INPLACE算法：多数结构变更（如添加索引、字段默认值修改）可在原表上操作，无需复制整表，减少IO开销。
- COPY算法：旧方式，需创建临时表复制数据，全程锁表，阻塞DML。
- INSTANT算法（MySQL 8.0.12+）：仅修改元数据，秒级完成，如快速添加非空默认值字段。
可通过ALGORITHM=INPLACE|COPY|INSTANT显式指定，但建议让MySQL自动选择最优方式。
常见在线DDL操作与影响评估
并非所有ALTER都真正“在线”。执行前应评估是否涉及锁表或长事务。以下为典型场景：
- 添加索引：支持INPLACE，允许并发DML，但会占用额外IO资源，建议在低峰期执行。
- 添加字段：MySQL 8.0+若使用INSTANT（如无默认值或有静态默认值），几乎无锁；否则可能触发表重建。
- 修改字段类型：通常需要COPY或INPLACE重建表，期间加S锁，阻塞写入，风险较高。
- 重命名字段或表：极快，一般不影响DML。
使用SHOW PROCESSLIST可观察DDL状态，如出现“waiting for meta data lock”表示被阻塞。
安全执行表结构变更的策略
为降低风险，应结合工具与流程制定标准化变更策略：
- 评估变更类型：使用EXPLAIN ALTER（需启用相关参数）或查阅官方文档确认是否支持在线执行。
- 选择合适时机：即使支持在线，大表操作仍可能影响性能，避开业务高峰。
- 使用pt-online-schema-change或gh-ost：对于不支持在线的变更，这些工具通过影子表+触发器/binlog同步实现零停机。
- 设置合理的timeout参数：如lock_wait_timeout、innodb_lock_wait_timeout，避免长时间阻塞。
- 监控执行过程：关注CPU、IO、主从延迟，及时发现异常。
生产环境建议实践
真实场景中，应遵循最小影响原则：
- 小字段变更优先使用原生ALTER，确保MySQL版本支持INSTANT或INPLACE。
- 大表或复杂变更使用gh-ost等工具，避免主库压力激增。
- 变更前备份表结构，准备回滚方案。
- 结合发布系统灰度上线，先在从库测试再推主库。
基本上就这些。关键是理解每种操作背后的执行方式，不盲目执行ALTER。
