MySQL Online DDL索引创建与锁表优化指南

1. MySQL索引创建与锁表机制深度解析

作为数据库管理员，我们经常需要在生产环境中对表结构进行调整，其中最常见的操作之一就是添加索引。记得我第一次在千万级用户表上执行CREATE INDEX时，整个应用几乎停滞了半分钟，那种心惊肉跳的感觉至今难忘。后来才发现，原来MySQL早已提供了更优雅的解决方案——Online DDL技术。

在MySQL 5.6之前，任何DDL操作（包括添加索引）都会导致表锁，这意味着在索引创建期间，所有对该表的读写操作都会被阻塞。这对于7×24小时运行的生产系统简直是灾难性的。但自从Online DDL出现后，我们终于可以在不影响业务的情况下完成索引创建，这背后的技术原理值得每个DBA深入了解。

2. Online DDL技术原理剖析

2.1 传统DDL与Online DDL对比

传统DDL操作采用"全表锁+数据复制"的工作模式。当执行ALTER TABLE添加索引时：

1. 获取表的排他锁(EXCLUSIVE LOCK)，阻塞所有读写操作
2. 创建临时表并复制原表数据
3. 在新表上创建索引
4. 用新表替换原表
5. 释放锁

这种方式的弊端显而易见：在步骤1-4期间，表完全不可用。对于GB级别的大表，这个过程可能持续数小时。

而Online DDL则采用了更智能的"原地修改"策略：

1. 仅获取元数据锁(MDL)，不阻塞DML操作
2. 在现有表空间内直接构建索引结构
3. 增量同步变更期间的数据修改
4. 短暂获取排他锁完成最终切换

2.2 Online DDL的核心参数详解

在实际使用中，我们需要特别关注两个关键参数：

ALGORITHM选项：

• INPLACE：最高效的模式，直接在原表空间操作
• COPY：退化为传统方式，需要创建临时表
• DEFAULT：由优化器自动选择

LOCK选项：

• NONE：最佳选择，允许并发读写
• SHARED：允许读但阻塞写
• EXCLUSIVE：完全锁定（等同于传统DDL）
• DEFAULT：系统自动选择

一个生产环境推荐的最佳实践示例：

sql复制ALTER TABLE user_orders 
ADD INDEX idx_order_time (order_time),
ALGORITHM=INPLACE, 
LOCK=NONE;

2.3 Online DDL的内部实现机制

Online DDL之所以能够不锁表，主要依赖于InnoDB的以下特性：

1. 写时复制(Copy-on-Write)：在索引构建期间，InnoDB会维护一个变更日志，记录所有DML操作
2. 增量应用：索引创建完成后，系统会将变更日志中的操作重新应用到新索引
3. 在线日志：使用特殊的online log临时存储并发事务对表的修改
4. 短暂排他锁：仅在最后切换阶段需要极短时间的锁

整个过程类似于git的分支管理——主分支(原表)继续接受提交(DML)，同时在特性分支(新索引)上工作，最后通过快速合并完成切换。

3. 实战中的注意事项与性能优化

3.1 Online DDL的适用场景与限制

虽然Online DDL很强大，但并非所有操作都支持：

完全支持的操作：

• 添加二级索引
• 重命名列
• 修改列默认值
• 删除索引

部分支持的操作：

• 添加主键（需要评估数据量）
• 修改列数据类型（某些类型转换不支持）
• 修改字符集（可能退化为COPY方式）

完全不支持的操作：

• 修改表空间
• 删除主键
• 某些特殊列类型的修改

3.2 大表索引创建的性能调优

对于超过1TB的超大表，即使使用Online DDL也可能对系统产生明显影响。以下是几个实测有效的优化技巧：

1. 分批创建：先在小规模数据上测试

sql复制-- 先在测试环境验证
CREATE TABLE test_table LIKE production_table;
INSERT INTO test_table SELECT * FROM production_table LIMIT 100000;
ALTER TABLE test_table ADD INDEX idx_test(...);

2. 控制资源使用：

sql复制SET GLOBAL innodb_online_alter_log_max_size=2147483648; -- 增大临时日志空间
SET GLOBAL innodb_sort_buffer_size=67108864; -- 增加排序缓冲区

3. 选择低峰期执行：即使不锁表，IO和CPU压力仍会影响性能

4. 监控进度：通过performance_schema可以查看进度

sql复制SELECT * FROM performance_schema.events_stages_current 
WHERE EVENT_NAME LIKE '%alter%';

3.3 常见问题排查指南

问题1：执行Online DDL时出现"ERROR 1799 (HY000)"错误

原因：临时日志空间不足
解决方案：增大innodb_online_alter_log_max_size参数

问题2：ALTER TABLE执行时间远超预期

可能原因：

1. 系统自动选择了COPY算法
2. 有未提交的长事务持有MDL锁
   排查方法：

sql复制SHOW PROCESSLIST;
SELECT * FROM information_schema.innodb_trx;

问题3：添加索引后查询性能反而下降

典型原因：基数(cardinality)统计不准确
解决方案：

sql复制ANALYZE TABLE table_name;

4. 版本差异与最佳实践

4.1 MySQL各版本对Online DDL的支持演进

• 5.5及之前：基本所有DDL都需锁表
• 5.6：引入基础Online DDL，支持二级索引的在线添加
• 5.7：增强支持更多操作类型，优化性能
• 8.0：原子DDL、即时添加列等重大改进

特别值得注意的是，MySQL 8.0引入了"INSTANT"算法，对于某些操作如添加可为NULL的列，可以在常数时间内完成：

sql复制ALTER TABLE users ADD COLUMN last_login_time TIMESTAMP NULL, ALGORITHM=INSTANT;

4.2 生产环境操作清单

为确保操作安全，建议遵循以下流程：

1. 检查表大小和结构

sql复制SELECT table_name, 
       round(((data_length + index_length) / 1024 / 1024), 2) as size_mb
FROM information_schema.TABLES 
WHERE table_schema = 'your_db';

2. 确认操作支持情况

sql复制SELECT * FROM information_schema.innodb_ddl_log;

3. 在测试环境验证
4. 制定回滚方案
5. 使用pt-online-schema-change等工具作为备选
6. 执行时监控性能指标
7. 验证结果并更新统计信息

5. 替代方案与高级技巧

对于特别敏感的生产环境，还可以考虑以下替代方案：

使用gh-ost工具：

bash复制gh-ost \
--user="dba" \
--password="xxx" \
--host="mysql-host" \
--database="your_db" \
--table="your_table" \
--alter="ADD INDEX idx_name (name)" \
--execute

Percona的pt-online-schema-change：

bash复制pt-online-schema-change \
--alter "ADD INDEX idx_email (email)" \
D=your_db,t=your_table \
--execute

这些工具采用触发器机制实现真正的零锁表，但代价是会产生更多的临时空间和复制开销。

在多年的DBA工作中，我发现最稳妥的做法是：对于小型表直接使用Online DDL；对于中型表在低峰期执行；对于超大型表则优先考虑专业工具。同时，建立完善的变更管理流程同样重要——每次索引添加都应该有明确的性能目标，并通过EXPLAIN验证执行计划是否按预期使用新索引。