MySQL 兼容与数据迁移方案

兼容性意味着什么

迁移成本的高低，主要取决于应用是否需要改代码。分布式数据库通常选择在协议层面对齐 MySQL，这样既有的驱动、ORM 框架和连接池可以继续使用，改造成本大幅下降。常见做法是兼容 MySQL 8.0 的协议与大部分语法，同时提供配套的数据迁移工具链。

但兼容不等于完全等价，迁移前必须逐项确认边界，避免上线后才发现行为差异。

以 TiDB 为例，其兼容性文档与源码分析中值得注意的点包括：

语句支持范围：部分语句并未完整支持，例如 REPLACE 在早期版本中就不在支持范围内，需要改成等价的 INSERT ... ON DUPLICATE KEY UPDATE 或先删后插；
索引语义：分布式数据库对值的获取都以 KV 操作为基础，索引更多是为了保证唯一性等约束与 MySQL 表现一致，而不是承担查询加速的全部职责；
事务隔离：默认隔离级别与 MySQL 不同，长事务和大事务的代价更高，需要重新审视事务边界；
自增与字符集：自增列在分布式环境下不保证连续，排序与字符集排序规则也需要实测验证。

经验做法：把生产库的慢查询日志和全量 SQL 采集出来，逐条在目标库上做兼容性回归，比只靠文档核对可靠得多。

导出 DDL 并在目标库重建。这个阶段要处理的是约束差异、索引策略和分片键选择。主键设计在这一步就要定好，因为它直接决定后续数据分布是否均匀。

把存量数据导出后并行导入目标库。此阶段的核心指标是吞吐与一致性，通常采用逻辑导出加并行导入的组合，并在导入完成后校验行数与关键字段的校验和。

在全量迁移期间，源库仍在写入，因此需要增量同步组件持续捕获变更并应用到目标库，使两边数据趋近一致。切换时通常按以下顺序执行：

迁移从来不是一次性的技术动作，而是一个需要反复验证的工程过程。把兼容性边界摸清、把回滚路径留好，切换才能真正做到低风险。