直接回答：MySQL 8.0 前多数 DDL 锁表或整表重建，大表直接改等于停服。方案三档：原生 Online DDL（8.0 的 INSTANT 加列秒级，但重建类操作仍有负载与主从延迟问题）、触发器影子表（pt-online-schema-change）、binlog 影子表（gh-ost）。核心思想一致：建新结构影子表、存量拷贝、增量同步、原子切换。
展开解析：两工具的原理差异决定风险差异：pt-osc 在影子表上建 INSERT/UPDATE/DELETE 触发器双写增量——触发器与原表同事务，高并发下锁竞争放大（触发器本质是给每次写加锁开销），且触发器故障窗口难察觉；gh-ost 伪装从库拉 binlog 应用增量——无触发器无额外锁，支持暂停（throttle 按主从延迟/负载指标）、可交互控制（限速、取消）、cut-over 可延迟到低谷。共同风险清单：磁盘——影子表双倍空间，磁盘不足直接事故；主从延迟——拷贝期写入量翻倍，从库延迟飙高，gh-ost 的 throttle 就是为此；切换窗口——rename 原子但需短暂元数据锁，有长事务时切换排队反堵全表（MDL 等待雪崩是线上高发事故：DDL 等 MDL，后续所有查询排队在 DDL 后面）；无主键表——增量同步无法行级定位，两工具都拒绝或降级。流程纪律：先在从库演练测时长、监控磁盘与延迟阈值、cut-over 选低谷、回滚预案（影子表rename回去）。8.0+ 的取舍：加列用 INSTANT 原生；加索引用 INPLACE 观察进度（performance_schema）；改列类型/分区这类重建仍走 gh-ost。PG 对照：CREATE INDEX CONCURRENTLY 内建但同样两阶段扫描有失败窗口。
追问方向：MDL 雪崩的形成链条与监控手段？gh-ost 的 cut-over 为什么需要原子改名两表？
（约 500 字）