DDL必须写入binlog，因其是元数据变更的逻辑锚点，跳过会导致主从结构失配、复制中断、备份断裂；INSTANT等优化仅加速执行层，仍需生成binlog事件。
因为DDL操作本身不走InnoDB事务路径，无法绕过binlog直接落盘——MySQL强制要求DDL必须以完整事件形式写入binlog，否则主从复制、GTID对齐、崩溃恢复全部失效。
DDL为什么不能像DML那样跳过binlog加速？
很多人误以为关掉sql_log_bin=0就能让ALTER TABLE变快，但这是危险操作：DDL不是“可选记录”的语句，而是元数据变更的逻辑锚点。一旦跳过binlog，从库就永远不知道表结构变了，后续所有INSERT/UPDATE都会因列数不匹配、字段类型缺失而失败或静默丢弃。
-
ALTER TABLE t ADD COLUMN c VARCHAR(32)不进binlog → 从库仍按旧结构解析binlog row event，报错Column c doesn't exist - 备份工具（如
mysqldump --single-transaction）依赖binlog position做一致性快照，跳过DDL会导致位点断裂 - 启用GTID时，
sql_log_bin=0下的DDL不生成GTID，从库SQL线程直接报ER_NO_EXECUTED_GTID_SET并中断
INSTANT DDL快，但依然要写binlog
MySQL 8.0.12+的ALGORITHM=INSTANT确实能做到秒级加字段，因为它只改数据字典、不动行数据。但这只是执行层优化，不是日志层豁免——它仍会生成一个QUERY_EVENT（statement格式）或GTID_LOG_EVENT（ROW/MIXED格式），确保该变更被完整广播出去。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 即使
INSTANT不锁表、不读数据页，sync_binlog=1下仍需fsync一次binlog文件才能返回成功 - 若手动设
sql_log_bin=0再执行INSTANT，虽然主库快了，但从库结构立即失配，后续任何DML都可能出错 -
INPLACE和COPY算法更依赖binlog：前者需靠binlog事件标记重建完成点，后者靠binlog保证临时表与原表切换的原子性
想真正提速DDL，别动binlog，换执行策略
binlog是底线，不是瓶颈。真正卡住DDL的是MDL锁争用、磁盘IO或单线程回放。与其试图绕过binlog，不如针对性解决：
- 用
ALTER TABLE ... ALGORITHM=INSTANT, LOCK=NONE确认是否满足条件（无全文索引、非分区表、非虚拟列等） - 大表DDL避开业务高峰，并提前在从库开启
slave_parallel_type=WRITESET和slave_parallel_workers=4 - 对千万级以上表，直接上
gh-ost：它靠解析binlog捕获变更，把DDL拆成小事务，不阻塞主库MDL，也不依赖从库单线程回放 - 检查
innodb_flush_log_at_trx_commit和sync_binlog配置——这两项同时为1时，DDL返回慢不是因为binlog本身，而是双刷盘开销
真正容易被忽略的点是：DDL的“快”从来不在日志写入路径上，而在它能否被复制系统安全承接。你看到的延迟，90%来自从库SQL线程串行执行，而不是主库写binlog花了多少毫秒。
