mysql 8.0.12+千万级表加字段可秒级完成：末尾添加允许null且无非空default的列支持algorithm=instant，仅改元数据；若含not null default则退化为inplace或copy，需提前校验引擎、显式指定algorithm=instant和lock=none，失败时降级pt-osc或gh-ost。
MySQL千万级表做DDL，不加干预基本必锁表数小时——但只要选对方案+校验条件，10分钟内完成、业务无感是常态。
确认 ALGORITHM=INSTANT 是否可用
MySQL 8.0.12+ 添加允许 NULL 的字段（不含 DEFAULT 值或含 DEFAULT NULL）可走元数据变更，真正“零拷贝”。但一旦带 NOT NULL DEFAULT 'xxx'，哪怕只是字符串，就会退化为全表扫描填充，默认触发 ALGORITHM=INPLACE 甚至 COPY。
- 执行前务必用
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME LIKE '%your_table%'确认表引擎是InnoDB - 测试语句必须显式指定：
ALTER TABLE your_table ADD COLUMN remark VARCHAR(255), ALGORITHM=INSTANT, LOCK=NONE; - 若报错
ALGORITHM=INSTANT is not supported for this operation，说明操作不支持 INSTANT，需降级到 INPLACE 或换工具
pt-online-schema-change 触发器写入延迟怎么压
pt-osc 在主表上建 INSERT/UPDATE/DELETE 三类触发器，高并发写入下可能堆积。它本身不阻塞主流程，但触发器执行慢会导致 chunk 迁移卡住、binlog 日志积压、从库延迟。
- 加参数
--max-load="Threads_running=25"主动限流，避免触发器吃光连接资源 - 禁用外键：
--no-check-alter+ 手动确保新旧表外键一致性，否则触发器会因约束检查变慢 - 避开主键非自增场景：若用 UUID 或复合主键，
--chunk-index必须指定高效索引，否则WHERE范围扫描变全表
gh-ost 切换前最后几秒为什么还会抖
gh-ost 最终 RENAME TABLE 是原子操作，但切换瞬间有极短窗口：原表不可写 → 新表就绪 → 应用连接重连。这个“抖”不是锁表，而是应用层 DNS 缓存、连接池未及时感知新表结构导致的短暂失败。
- 必须开启
binlog_format=ROW，否则 gh-ost 无法解析变更，会 fallback 到 polling 模式，大幅增加延迟 - 用
--cut-over-lock-timeout-seconds=3控制重试等待上限，避免卡在锁竞争里 - 上线前在测试环境跑一次
--dry-run，观察gh-ost-status输出中throttle-control-reason是否频繁触发
别忽略主从延迟和连接池刷新
再平滑的 DDL，在主从架构下也绕不开 binlog 回放延迟。尤其 gh-ost 和 pt-osc 都依赖 binlog 同步，主库切完，从库还没追上，读请求打到从库就会查不到新字段。
- 切表前用
SHOW SLAVE STATUS\G确保Seconds_Behind_Master = 0，否则先 stop slave 等追平 - 应用连接池（如 HikariCP）要配置
connection-test-query=SELECT 1和合理validation-timeout，避免复用旧连接执行含新字段的 SQL 报Unknown column - 如果用了读写分离中间件（如 ShardingSphere、MyCat），DDL 后需手动触发元数据刷新，否则路由规则仍按旧结构匹配
真正难的从来不是工具调通，而是把“表结构变了”这件事，同步进数据库、中间件、应用连接池、监控告警、甚至开发同学的本地 SQL 脚本里——漏掉任意一环，都可能在凌晨三点弹出一个 Column not found。
