MySQL复制中执行DDL需谨慎以避免数据不一致或中断。1. SBR模式下DDL以语句形式复制，但非确定性操作可能导致主从差异；2. RBR模式下DDL仍以语句传输，ALTER引发的数据变更可能增加延迟；3. 安全实践包括从库预验证、使用pt-online-schema-change工具、避开高峰期及检查复制状态；4. 出错时应分析错误日志，慎用跳过错误或手动修复结构，必要时重建从库。保持环境一致与规范操作是关键。
MySQL在复制环境中处理DDL（数据定义语言）操作需要特别注意，因为DDL语句会修改数据库结构，若处理不当可能导致主从数据不一致或复制中断。以下是一些常见场景和推荐做法，帮助你在复制中安全执行DDL操作。
1. DDL在基于语句的复制（SBR）中的行为
在基于语句的复制模式下，主库执行的DDL语句（如 CREATE、ALTER TABLE、DROP）会直接记录到二进制日志中，并发送给从库执行。这种方式通常能正确复制DDL，但存在一些潜在问题：
- 如果DDL语句包含非确定性函数或依赖当前时间，可能在从库上产生不同结果。
- 某些DDL操作（如ALTER TABLE）在主库长时间运行时，会阻塞其他写操作，影响复制延迟。
- 若从库缺少对应数据库或表，执行DDL会失败。
2. DDL在基于行的复制（RBR）中的表现
在RBR模式下，二进制日志主要记录数据变更的“行”级别变化，但DDL仍以语句形式记录（即使binlog_format=ROW）。这意味着ALTER TABLE等操作依然以SQL语句方式传送到从库执行。
- DDL本身不会以“行事件”传输，因此不受RBR限制。
- 但ALTER期间引发的数据变更（如重建表）可能生成大量行事件，增加复制延迟。
3. 安全执行DDL的最佳实践
为避免复制中断或数据异常，推荐以下操作方式：
- 先在从库验证：对于复杂的ALTER操作，可先在从库测试，确认兼容性和执行时间。
- 使用pt-online-schema-change：Percona Toolkit提供的工具可在不锁表的情况下修改表结构，适合大表在线变更。
- 避免在高峰期执行DDL：减少对主库性能和复制延迟的影响。
-
检查从库状态：执行前确认
SHOW SLAVE STATUS中复制正常，无延迟。 - 跨版本复制要小心：主从MySQL版本不一致时，某些DDL语法可能不兼容。
4. 处理DDL导致的复制错误
如果DDL执行后从库报错（如表不存在、语法错误），可采取以下措施：
- 查看错误信息：
SHOW SLAVE STATUS\G中的Last_Error字段。 - 若错误可忽略（如DROP TABLE IF NOT EXISTS未找到表），可用
SET GLOBAL sql_slave_skip_counter=1跳过错误事务（慎用）。 - 更安全的方式是停止从库，手动修复结构后重启复制。
- 必要时重新搭建从库，确保结构完全同步。
基本上就这些。只要保持主从结构一致，选择合适时机和工具执行DDL，MySQL复制可以稳定处理结构变更。关键是提前评估风险，避免直接在生产主库上试错。
