1. MySQL Online DDL核心概念与演进历程

第一次在生产环境执行大表DDL变更时，我盯着那个持续了6小时的ALTER TABLE操作，看着监控里飙升的CPU和磁盘IO，深刻理解了为什么DBA们会把DDL称为"数据库的午夜噩梦"。MySQL的Online DDL功能正是为了解决这个痛点而生，它允许我们在不锁表或短暂锁表的情况下完成结构变更。

从MySQL 5.5开始引入的INPLACE算法（虽然实际仍会阻塞DML），到5.6真正实现不阻塞DML的Online DDL，再到8.0的INSTANT秒级操作，这个演进过程就像数据库版本的"工业革命"：

• 5.5时代：如同手工作坊，添加索引需要全表拷贝，业务高峰期不敢操作
• 5.6革新：引入真正的Online DDL，支持并发DML，类似蒸汽机带来第一次飞跃
• 5.7优化：增强VARCHAR字段修改等场景，如同内燃机改进
• 8.0突破：INSTANT算法实现元数据级修改，堪比电气化革命

在8.0.12版本中，我曾实测给亿级用户表新增列（非末尾位置），传统方式需要小时级完成，而使用ALGORITHM=INSTANT仅耗时0.01秒。这种体验差异就像从绿皮火车突然切换到高铁。

2. 算法选择：INSTANT/INPLACE/COPY的实战决策

去年双十一前，我们需要对订单表新增三个索引。面对三种算法选择，我是这样决策的：

INSTANT算法（秒级操作）：

-- 8.0+版本添加普通索引（实测50毫秒完成） ALTER TABLE orders ADD INDEX idx_buyer(buyer_id), ALGORITHM=INSTANT;

适用场景：添加索引、修改列默认值等元数据操作。但要注意：

• 添加自增列仍需重建表
• 修改列数据类型不支持

INPLACE算法（分钟级~小时级）：

-- 添加组合索引（数据量1TB耗时23分钟） ALTER TABLE order_items ADD INDEX idx_composite(product_id,sku_id), ALGORITHM=INPLACE, LOCK=NONE;

适用场景：90%的DDL操作，包括：

• 添加/删除二级索引
• 修改NULL约束
• 扩展VARCHAR长度（0-255字节间调整）

COPY算法（慎重使用）：

-- 修改主键必须使用COPY（生产环境慎用！） ALTER TABLE payments DROP PRIMARY KEY, ADD PRIMARY KEY(txn_id), ALGORITHM=COPY;

典型坑点案例：某次将CHAR(32)改为VARCHAR(32)，本以为INPLACE可行，实际触发了COPY算法导致服务不可用2小时。后来发现字符集变更都会强制COPY算法。

3. 锁机制深度解析与避坑指南

LOCK参数看似简单，但我在阿里云客户现场见过至少5起生产事故源于错误配置：

LOCK=NONE（最佳实践）：

-- 安全添加索引（允许所有DML） ALTER TABLE users ADD INDEX idx_phone(phone), ALGORITHM=INPLACE, LOCK=NONE;

风险点：如果存在长事务，可能遇到：

ERROR 1205 (HY000): Lock wait timeout exceeded

LOCK=SHARED（折中选择）：

-- 允许查询但阻塞写入 ALTER TABLE products MODIFY COLUMN price DECIMAL(10,2), ALGORITHM=INPLACE, LOCK=SHARED;

适用场景：数据校验类操作

LOCK=EXCLUSIVE（极端情况）：

-- 维护窗口期使用（完全不可读写） ALTER TABLE logs CONVERT TO CHARACTER SET utf8mb4, ALGORITHM=COPY, LOCK=EXCLUSIVE;

真实案例：某金融客户在交易时段执行DDL，虽然指定LOCK=NONE，但因存在未提交事务导致MDL锁等待链式反应。最终通过以下查询定位问题：

SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA='finance_db';

4. 生产环境避坑全攻略

经过数十次血泪教训，我总结出这套操作清单：

前置检查清单：

1. 确认无长事务：

SELECT * FROM information_schema.innodb_trx WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;

2. 检查表大小：

SELECT table_name, ROUND(data_length/1024/1024) AS size_mb FROM information_schema.tables WHERE table_schema = 'your_db';

执行中监控：

# 查看DDL进度（5.7+） SELECT * FROM information_schema.innodb_alter_table;

参数调优建议：

# my.cnf关键参数 innodb_online_alter_log_max_size=1G # 默认128M innodb_sort_buffer_size=64M # 默认1M

经典错误处理：

1. 空间不足报错：

-- 临时解决方法 SET GLOBAL innodb_online_alter_log_max_size=1073741824;

2. 主从延迟处理：

-- 从库执行 STOP SLAVE SQL_THREAD; START SLAVE SQL_THREAD;

版本差异矩阵：

在金融级业务中，我们最终形成的SOP是：先在从库执行→主从切换→再修改原主库。对于10TB+的表，则采用pt-osc或gh-ost工具。