千万级大表如何优雅地新增字段？DBA都不会告诉你的秘密！

作为一名资深后端开发，你有没有遇到过这样的场景：产品经理跑过来说："我们这个用户表要加个新字段，用来记录用户的最后登录时间，今天就要上线！"

你一看表结构，好家伙，用户表已经5000万数据了，直接执行ALTER TABLE语句？那岂不是要锁表半小时，整个系统都得瘫痪？

今天就来聊聊如何优雅地给千万级大表新增字段，让你的系统在不宕机的情况下完成表结构变更！

一、为什么大表新增字段这么难？

在开始讲解决方案之前，我们先来理解一下为什么给大表新增字段会这么困难：

1.1 传统ALTER TABLE的痛点

在MySQL 5.5及更早版本中，执行ALTER TABLE ADD COLUMN操作时会发生什么？

1. 锁表：整个表会被锁定，无法进行任何读写操作
2. 重建表：MySQL会创建一个新表，将原表数据逐行复制到新表
3. 时间长：数据量越大，复制时间越长，锁表时间也越长

对于5000万数据的表，这个过程可能需要几十分钟甚至几小时，期间系统完全不可用！

1.2 现代MySQL的改进

MySQL 5.6引入了Online DDL功能，MySQL 8.0更是增加了INSTANT算法，大大改善了这个问题。但即使如此，在超大表上执行ALTER TABLE仍然存在风险。

二、主流解决方案对比

面对大表新增字段的需求，业界主要有以下几种解决方案：

2.1 MySQL原生Online DDL

MySQL 5.6+版本支持Online DDL，可以通过以下方式执行：

ALTER TABLE user_table 
ADD COLUMN last_login_time DATETIME DEFAULT NULL,
ALGORITHM=INPLACE, LOCK=NONE;

优点：

• 无需额外工具
• 支持并发DML操作

缺点：

• 仍需要双倍磁盘空间
• 某些操作不支持在线执行
• 可能导致主从延迟

2.2 pt-online-schema-change工具

这是Percona公司开发的开源工具，专门用于在线表结构变更。

工作原理：

1. 创建与原表结构相同的新表
2. 在新表上执行ALTER操作
3. 创建触发器同步数据变更
4. 逐步将原表数据复制到新表
5. 原子性切换表名

2.3 gh-ost工具

GitHub开源的在线表结构变更工具，与pt-osc类似但实现方式不同。

三、pt-online-schema-change实战详解

接下来我们重点介绍pt-online-schema-change的使用方法，这是目前业界最主流的解决方案。

3.1 安装Percona Toolkit

# CentOS/RHEL
yum install percona-toolkit

# Ubuntu/Debian
apt-get install percona-toolkit

# 或者直接下载安装
wget https://www.percona.com/downloads/percona-toolkit/LATEST/binary/redhat/7/x86_64/percona-toolkit-3.4.0-x86_64-redhat-linux-gnu.tar.gz
tar -xzf percona-toolkit-3.4.0-x86_64-redhat-linux-gnu.tar.gz

3.2 基本使用方法

给用户表添加last_login_time字段的完整命令：

pt-online-schema-change \
--host=localhost \
--user=root \
--password=your_password \
--port=3306 \
--charset=utf8mb4 \
D=your_database,t=user_table \
--alter="ADD COLUMN last_login_time DATETIME DEFAULT NULL COMMENT '最后登录时间'" \
--execute

3.3 关键参数详解

# 安全参数
--no-version-check    # 跳过版本检查
--dry-run            # 模拟执行，不真正修改表结构
--print              # 打印将要执行的SQL语句

# 性能参数
--chunk-size=1000    # 每次处理的行数，默认1000
--max-load="Threads_running=25"  # 最大负载限制
--critical-load="Threads_running=50"  # 危险负载阈值
--sleep=1            # 每次操作后休眠时间（秒）

# 复制参数
--check-slave-lag=h=slave_host  # 检查从库延迟
--max-lag=1          # 最大延迟时间（秒）

3.4 完整示例

pt-online-schema-change \
--host=127.0.0.1 \
--user=root \
--password=your_password \
--port=3306 \
--charset=utf8mb4 \
--no-version-check \
--chunk-size=2000 \
--max-load="Threads_running=25" \
--critical-load="Threads_running=50" \
--sleep=0.5 \
--check-slave-lag=h=192.168.1.100,P=3306 \
--max-lag=1 \
--recursion-method=processlist \
D=your_database,t=user_table \
--alter="ADD COLUMN last_login_time DATETIME DEFAULT NULL COMMENT '最后登录时间', ADD INDEX idx_last_login_time (last_login_time)" \
--execute

四、执行过程详解

pt-online-schema-change的执行过程可以分为以下几个阶段：

4.1 初始化阶段

1. 检查表是否存在主键或唯一索引（必须有）
2. 创建新表（表名格式：_原表名_new）
3. 在新表上执行ALTER操作

4.2 数据复制阶段

1. 创建三个触发器（INSERT、UPDATE、DELETE）
2. 分批将原表数据复制到新表
3. 通过触发器同步复制期间的数据变更

4.3 切换阶段

1. 原子性重命名表（RENAME操作）
2. 删除旧表和触发器
3. 完成表结构变更

五、安全注意事项

使用pt-online-schema-change时需要注意以下安全事项：

5.1 前置检查

1. 必须有主键或唯一索引：否则工具会拒绝执行
2. 磁盘空间：确保有足够的磁盘空间（至少2倍表大小）
3. 从库延迟：监控从库延迟，避免影响复制

5.2 执行监控

# 查看执行进度
ps aux | grep pt-online-schema-change

# 监控MySQL状态
show processlist;

# 查看表大小
SELECT 
  table_name,
  ROUND(((data_length + index_length) / 1024 / 1024), 2) AS 'Size in MB'
FROM information_schema.tables 
WHERE table_schema = 'your_database' 
AND table_name = 'user_table';

5.3 异常处理

如果执行过程中出现问题，工具会自动回滚：

1. 删除新表
2. 删除触发器
3. 保持原表不变

六、性能优化建议

6.1 选择合适的执行时间

• 避开业务高峰期
• 选择数据库负载较低的时段
• 考虑从库的同步压力

6.2 调整参数优化性能

# 根据服务器性能调整chunk-size
--chunk-size=5000    # 数据量大时可以适当增大

# 调整并发度
--concurrent=10      # 并发线程数

# 优化休眠时间
--sleep=0.1          # 减少休眠时间提高效率

6.3 监控关键指标

1. CPU使用率：避免CPU过载
2. IO等待：监控磁盘IO性能
3. 内存使用：确保有足够的内存
4. 从库延迟：监控复制延迟

七、总结

给千万级大表新增字段看似是一个简单的DDL操作，实际上却蕴含着很多技术细节和风险。通过合理选择工具和方法，我们可以实现：

1. 零停机时间：业务无感知的表结构变更
2. 数据一致性：确保变更过程中数据不丢失
3. 安全可靠：完善的异常处理和回滚机制
4. 性能可控：可调节的执行参数和监控指标

掌握了这些技巧，相信你再面对大表结构变更时会更加从容不迫，让你的系统稳如老狗！

今日思考：你们团队在处理大表结构变更时都采用什么方案？有没有遇到过什么坑？欢迎在评论区分享你的经验！