MySQL主从架构下直接执行DDL会导致同步延迟，因为大表DDL持有MDL锁阻塞读写，且ROW格式binlog中DDL仍以statement方式记录，从库无法并行回放；gh-ost通过影子表+binlog增量同步实现无锁变更，仅产生轻量DML和一次RENAME，避免锁表与复制阻塞。
MySQL主从架构下直接执行DDL为什么会导致同步延迟
因为 ALTER TABLE 在主库上执行时，会以「语句级」或「行级」方式写入 binlog，而大表 DDL 会持有元数据锁（MDL），阻塞后续读写；从库回放时若表数据量大、IO 或 CPU 资源不足，就会卡在 altering table 状态，导致 Seconds_Behind_Master 持续上涨，甚至堆积 relay log。
更麻烦的是：5.7+ 默认 binlog_format=ROW，但 DDL 仍以 statement 形式记录（即使开了 binlog_row_image=FULL 也无效），从库必须等整个 DDL 执行完才继续，无法并行回放。
为什么 Ghost（gh-ost）能绕过同步延迟问题
gh-ost 不依赖 MySQL 原生 DDL，而是用「影子表 + 增量日志解析」方式实现无锁变更：它在主库上创建新表结构，通过监听 binlog 捕获原表的增删改操作，并实时同步到影子表；待全量拷贝完成、增量追平后，用原子 RENAME 切换表名——整个过程不阻塞主库写入，从库只看到轻量的 INSERT/UPDATE/DELETE 和最终一次 RENAME，几乎不影响复制延迟。
关键点：
-
gh-ost默认连接主库执行，但所有写操作都走主库，从库仅被动回放，因此不会加剧从库压力 - 它不使用触发器（对比
pt-online-schema-change），规避了触发器在 GTID 模式下的兼容性问题 - 支持
--allow-on-master强制在主库运行，也支持--assume-rbr明确告知已开启 ROW 格式 - 通过
--max-load和--critical-load控制对主库负载的影响，避免因拷贝拖慢线上业务
gh-ost 实际执行时必须注意的参数和条件
不是加几个参数就能跑起来，漏掉关键约束会失败或引发主从不一致：
- 主库必须开启
binlog_row_image=FULL（MySQL 5.6.22+），否则无法捕获完整变更字段 - 用户需有
SELECT、INSERT、UPDATE、DELETE、DROP、CREATE权限，且能访问information_schema - 必须指定唯一可排序索引（如主键或带
NOT NULL的唯一索引），gh-ost靠它分块读取原表，否则报错Cannot find a unique key - 避免在从库上执行 ——
gh-ost不支持--host指向从库，它需要直连主库解析 binlog - DDL 语句要写进
--alter参数里，例如：--alter="ADD COLUMN status TINYINT DEFAULT 0"，不能带ALTER TABLE t1
典型命令示例：
gh-ost \ --user="root" \ --password="xxx" \ --host="master-host" \ --database="mydb" \ --table="orders" \ --alter="ADD COLUMN updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP" \ --assume-rbr \ --allow-on-master \ --cut-over-exponential-backoff \ --chunk-size=1000 \ --max-load="Threads_running=25" \ --critical-load="Threads_running=50" \ --initially-drop-ghost-table \ --initially-drop-old-table \ --execute
主从延迟没消失？可能是 gh-ost 自身触发了复制瓶颈
gh-ost 虽不锁表，但全量拷贝阶段会持续发起 SELECT，增量阶段高频写入影子表，这两者都会增加主库压力；如果主库本身 IO 已饱和，或者从库的 slave_parallel_workers 设置过低，依然可能看到短暂延迟上升。
这时候要查的不是 gh-ost 是否出错，而是：
- 主库
SHOW PROCESSLIST中是否有大量gh-ost的COPY连接占着连接数 - 从库
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否在切表完成后快速归零 - 是否误启用了
--throttle-control-replicas却没配对从库地址，导致 gh-ost 主动降速 - 表上有大字段（如
TEXT、BLOB）时，--chunk-size设太大容易触发max_allowed_packet错误，建议先调小测试
真正难处理的不是工具怎么用，而是你得清楚当前主从拓扑里哪一环最脆弱：是主库磁盘吞吐？从库 SQL 线程单点？还是网络抖动让 binlog 传输变慢？gh-ost 只负责不添乱，但压不住底层瓶颈。
