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花了多少毫秒。