一、深层次原因分析
1. Online DDL机制
MySQL 5.6及以上版本支持Online DDL操作，允许在执行DDL时对表进行并发的DML操作。在Online DDL过程中，会记录并发执行的DML操作到row log中，并在DDL操作的最后阶段应用这些DML操作。如果这些DML操作中存在违反唯一键约束的情况，就会导致错误。
2. 唯一键冲突的产生
当对大表执行DDL操作时，如果在操作过程中有其他会话对同一表执行了导致唯一键冲突的DML操作（如插入重复值），则DDL操作可能会失败，并报出唯一键冲突的错误。这是因为InnoDB引擎在应用DML操作时，会检查唯一键约束，即使这些冲突在最终的数据状态中可能并不存在
二、解决方案
1. 使用第三方工具
-
pt-osc：由Percona公司开发，支持多种DDL操作，通过创建一个空表，逐步将原表的数据迁移到新表，并在最后进行快速切换，减少对业务的影响。
-
gh-ost：由GitHub开发，采用类似pt-osc的思路，但在实现上有一些差异，如使用更少的锁机制，进一步降低对业务的干扰。
2. 关闭唯一性检查（谨慎使用）
在执行DDL操作前，通过设置SET SESSION unique_checks=0;来暂时关闭唯一性检查。但需要注意，这可能会导致数据的不一致性，因此在操作完成后应及时重新开启检查。
在DDL SQL中添加lock=share或lock=EXCLUSIVE可以改变DDL操作期间对表的锁机制，从而影响并发DML操作的行为。
3. 禁止DML
使用lock=SHARE或lock=EXCLUSIVE
-
lock=SHARE：允许并发的SELECT操作，但会阻塞INSERT、UPDATE和DELETE操作。这可以在一定程度上减少唯一键冲突的可能性，因为减少了并发写入操作。 -
lock=EXCLUSIVE：完全阻塞所有其他类型的访问，包括SELECT、INSERT、UPDATE和DELETE操作。这可以确保在DDL操作期间没有任何其他会话修改表数据，从而避免唯一键冲突。
然而也会带来一些负面影响：
-
业务影响：长时间的锁表操作会影响业务的正常运行，尤其是对于高并发的系统。
-
性能问题：锁表操作可能导致系统资源的浪费和性能的下降。
因此，虽然lock=share或lock=EXCLUSIVE可以避免唯一键冲突，但它们并不是最佳的解决方案。在实际应用中，应根据具体情况权衡利弊，选择最适合的解决方案。
原文档地址： https://cloud.tencent.com/developer/article/1520220
原文档地址：Mysql online DDL特性（一）_**但是对于主库同步过来dml,此时会被阻塞,是offline的**,ddl是排他锁的在复制线程-CSDN博客