Online DDL工具的隐藏坑：本该保护数据的工具，在特定场景下反而会导致数据丢失

应对Online DDL这个长期困扰MySQL用户的问题，业界主流方案有三类：MySQL原生支持方式、pt-osc（pt-online-schema-change）和gh-ost这类第三方工具、以及先修改从库再通过主从切换来完成修改。其中pt-osc是使用最通用、最广泛的方案，但它有几个容易被忽视、却真实会造成数据丢失的坑：一是如果表内存在重复数据、这时又要给这个表添加唯一键约束，pt-osc在处理过程中可能会导致这些重复数据被直接丢弃、无法保留（因为唯一键约束天然不允许重复值存在，而pt-osc要在不停机的前提下完成这个结构变更，处理重复数据冲突时采取的策略可能是直接舍弃）；二是在使用row格式binlog的场景下，如果只在从库上执行pt-osc操作，同样有可能造成数据丢失。这两个坑的共同点是：它们不是pt-osc这个工具”用错了”或者”配置错了”导致的低级失误，而是这个工具本身在特定数据状态（存在重复数据）或特定复制配置（只在从库执行、row格式）下，客观存在的行为盲区——即使按照文档正确使用这个工具，只要恰好撞上了这些特定场景，依然会真实地丢失数据。这个案例提示了一条使用任何”号称能安全完成某个高风险操作”的工具时都应该保持的谨慎：一个工具的名声再好、使用范围再广泛，也不意味着它在所有输入条件和部署场景下都绝对安全——真正负责任的使用方式，是提前了解并核实这个工具在自己实际数据状态（有没有重复数据）和部署拓扑（是不是要在从库单独执行、用的是什么binlog格式）下有没有已知的行为盲区，而不能只因为”这是业界最通用的方案”就默认它在自己的场景下也一定安全无虞。