先说一个核心判断：在MySQL主从复制架构中执行在线DDL变更，真正的难点并非主库，而是从库。直接在主库运行一条 ALTER TABLE，主库可能只需几秒完成，但从库却可能卡顿数十分钟，甚至引发复制中断。许多DBA和开发人员只有在线上遇到故障后，才深刻意识到从库延迟的严重性。
主从环境下的在线架构变更，本质目标只有一个：确保变更在主库生效的同时，不破坏从库的同步链路，避免数据不一致。这并非“能否执行”的问题，而是“如何安全执行”的核心挑战。
主库执行 Online DDL 时，从库为什么会出问题？
MySQL 的 Online DDL 在主库上看似无锁，但问题出在它的 binlog 记录方式。从库真正重放的不是你想象的“原地无锁操作”，而是 binlog 里写好的那个版本。
- 例如，
ADD COLUMN操作在 MySQL 5.6 及以上版本支持ALGORITHM=INPLACE，但 binlog 中仍可能以ALTER TABLE ... ALGORITHM=COPY形式记录——特别是当server_id不匹配或未显式指定参数时。这导致从库被迫重建表、锁定表，从而引发延迟飙升。 - 修改列的默认值（
ALTER COLUMN ... SET DEFAULT）直到 MySQL 8.0.23 之后才实现真正无锁。在旧版本中，即使主库不锁表，从库的 SQL 线程执行时仍会获取元数据锁（MDL），从而阻塞其他查询。 - 如果主库启用了
binlog_row_image=MINIMAL，部分 DDL 的 row event 可能缺失关键字段，进而触发从库的Last_SQL_Errno: 1785（事务依赖冲突）。
pt-online-schema-change 在主从环境下必须加的三个参数
使用 pt-online-schema-change 显然更稳妥，但一个容易被忽略的事实是：该工具默认只操作主库，对从库完全没有感知。不添加约束就跑，主从结构不一致的故障几乎是必然的。
--recursion-method=none：禁止自动探测从库，防止工具误判拓扑结构而连接错误节点。--check-slave-lag=h=slave_host,u=user,p=pass,P=3306：显式指定一个从库，持续监控Seconds_Behind_Master指标。一旦延迟超过 30 秒，工具自动暂停复制操作，避免从库追赶不上主库的写入节奏。--slave-user和--slave-password：确保工具能够在从库上执行SELECT COUNT(*)校验。如果遗漏这两个参数，校验步骤会被直接跳过，导致数据一致性失去保障。
这三个参数缺一不可，漏掉任何一个都可能导致“主库变更完成，从库仍在同步旧结构”的静默故障。更严重的是，这种故障往往难以察觉，直到引发数据不一致时才被发现。
GTID 模式下变更前必须验证的两个点
开启 GTID 之后，DDL 的原子性和可追溯性确实提升了不少，但代价是校验逻辑变得更严格。变更前有两件事必须确认：
- 在运行
pt-online-schema-change之前，先在主库执行SELECT @@global.gtid_executed;记录当前 GTID 集合。变更完成后，再到从库执行同样的查询，确认两个 GTID 集合完全一致——注意，不是“包含”，而是必须相等。 - 变更过程中严禁执行
SET GLOBAL sql_log_bin = 0。GTID 机制要求所有变更都必须写入 binlog，绕过日志会使得从库无法识别事务边界，后续的WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS命令也会完全失效。
切换后最容易被忽略的索引同步问题
很多团队把注意力全放在表结构上，忽略了索引在主从之间并不是“自动镜像”的。几个常见的坑：
- 在主库使用
ALGORITHM=INPLACE, LOCK=NONE添加二级索引时，但从库可能因磁盘 I/O 压力过大，SQL 线程在重放该 DDL 时降级为COPY模式，耗时数分钟。此时SHOW PROCESSLIST显示altering table，但应用层完全无法感知这一差异。 - 如果从库将
innodb_adaptive_hash_index设为OFF，而主库为ON，相同的 DDL 在从库上执行得更慢，延迟自然逐渐累积。 - 变更完成后立即在从库执行
SHOW INDEX FROM tbl_name，可能发现新索引存在但Cardinality值为 0——这表示统计信息尚未更新，需要手动执行ANALYZE TABLE，否则查询计划可能退化。
因此，一次完整的在线架构变更并非以主库返回 success 为终点。必须等到从库的 Slave_SQL_Running_State 恢复为 Waiting for next chunk，并且 Seconds_Behind_Master 稳定归零至少 60 秒，才能真正确认变更已安全落地。
