MySQL 单机跑得好好的，突然有一天磁盘告警、写入延迟飙升、主从延迟越来越长。团队开始讨论：是继续加硬件撑着，还是干脆换分布式数据库？
这个问题看起来是技术选型，但背后是一系列需要提前想清楚的评估项。漏掉任何一个，都可能在迁移过程中或上线后付出代价。
先确认：真的是分布式数据库的时机吗？
在评估具体产品之前，先回答一个前置问题：当前瓶颈的本质是什么？
写入瓶颈： 如果是单点写入容量不足（比如单机 QPS 到了上限），需要确认是 CPU 成为瓶颈还是磁盘 I/O 成为瓶颈。如果是 CPU，看看是不是有大量慢查询或缺乏合适索引；如果是 I/O，看看是不是日志写入过于频繁或缓冲池配置不合理。很多所谓的"写入瓶颈"，其实通过优化查询和调整参数就能缓解。
容量瓶颈： 如果是磁盘空间不够，先考虑数据归档和历史数据清理。很多业务表中 80% 的数据是冷数据，归档后可以延长当前架构的生命周期。
真正的信号： 只有在以下情况，才说明确实到了需要引入分布式数据库的阶段——单机硬件已经升到顶、读写分离已经做了但写入仍然是单点瓶颈、数据量持续增长且业务需要在线扩容能力。
五个核心评估维度
1. SQL 兼容性
这是迁移成本的第一道门槛。MySQL 用了大量特有语法和函数，不同分布式数据库的兼容程度差异较大。
需要重点检查的：
- MySQL 特有函数： GROUP_CONCAT、FIND_IN_SET、IFNULL 等，部分产品有对应实现，但行为细节可能有差异
- 数据类型差异： MySQL 的 DATETIME、TINYINT、ENUM 等类型在不同数据库中的精度和范围可能不同
- 字符集和排序规则： MySQL 默认 utf8 实际上是 utf8mb3（最多3字节），部分分布式数据库默认使用 utf8mb4，可能导致存储空间和索引长度的差异
- SQL Mode： MySQL 的宽松 SQL Mode（如默认允许"0000-00-00"日期）在严格模式下会报错
2. 事务模型
MySQL 使用单机事务，所有操作在一个节点内完成，ACID 保证相对简单。不同分布式数据库的事务机制差异较大。
需要评估的：
- 事务隔离级别： 不同产品的 RR 实现方式不同（有些基于 MVCC 快照，有些基于锁），需要逐产品确认
- 分布式事务开销： 跨节点的两阶段提交会增加延迟，对于延迟敏感的短事务，需要关注额外开销有多大
- 大事务支持： 部分产品对单事务的数据量或持锁时间有限制，如果业务中存在大批量更新操作，需要特别确认
3. 扩展能力和架构
引入分布式数据库的核心目的就是扩展，但不同产品的扩展方式差异很大。
- 水平扩展方式： 是自动分片还是手动指定分片键？自动分片降低了运维复杂度，但可能对查询模式有要求
- 在线扩容： 加节点后数据能不能自动重分布？重分布过程中对线上业务的影响有多大？
- 扩容上限： 理论上分布式数据库可以无限扩展，但实际上网络带宽、协调节点性能都会成为天花板
- 存储计算分离： 存储和计算能否独立扩展？对于读多写少或分析负载重的场景，这个能力很关键
4. 运维复杂度
从单机 MySQL 到分布式数据库，运维难度是质的飞跃。
- 监控体系： 分布式环境下，单节点指标不够用了，需要集群级别的监控视图
- 故障排查： 单机 MySQL 的慢查询日志在分布式环境下分散在多个节点，需要统一的查询分析工具
- 备份恢复： 不同产品的备份策略不同，需要确认是全量+增量还是快照方式，恢复时间是多久
- 版本升级： 分布式数据库的升级通常比单机复杂，需要关注是否支持在线滚动升级
5. 性能基线和回归测试
迁移前必须建立性能基线，迁移后做回归对比。不能只看"能不能跑通"，要看"跑得怎么样"。
- 核心接口的 P99 延迟： 这是用户体验最直接的指标
- 吞吐量上限： 在相同硬件总量下，目标数据库的吞吐是否满足预期
- 热点问题： 不同产品对热点的处理能力不同，如果业务存在明显的数据热点，需要提前验证
- 连接数模型： MySQL 的连接是直连模式，部分分布式数据库有代理层，连接管理方式不同，可能影响应用配置
一个容易忽视的问题：迁移路径
评估完分布式数据库本身，还要评估怎么迁过去。
- 如果目标数据库兼容 MySQL 协议，迁移工具的选择会多很多，应用层的改动也最小
- 如果协议不兼容，除了数据迁移，还涉及应用驱动、连接池、ORM 框架的适配
- 迁移过程中的数据一致性校验方案也要提前设计
TiDB 在 MySQL 升级评估中的对应能力
TiDB 兼容 MySQL 协议，应用层基本不需要改连接方式，数据迁移可以使用 DM 工具完成从 MySQL 到 TiDB 的全量和增量同步。TiDB 支持在线扩容，加节点后数据自动重分布；存储计算分离架构下，TiFlash 列存节点可以独立扩展分析能力。事务方面，TiDB 默认 RC 隔离级别，基于 Multi-Raft 实现分布式事务，适合从 MySQL 单机平滑升级。
如果你正在评估 MySQL 到分布式数据库的升级，建议先做一轮 SQL 兼容性扫描和性能基线测试，再结合业务扩容需求确定选型方向。