作者： TiDBer_leaf 原文来源：https://tidb.net/blog/5323d5c1

作为公司负责数据库运维与优化的 DBA，最近牵头完成了 TiDB 敏捷模式的落地测试，核心目标是验证其能否解决当前 MySQL 架构的瓶颈。先直接上结论：用接近单机 MySQL 的成本，拿到了分布式数据库的全套能力，完全符合业务“小步快跑、平滑演进”的需求，这篇就从实操角度跟大家聊聊整个过程。

一、背景：MySQL 单机架构的“四座大山”

我们当前支撑的业务不算超大规模，但对数据库要求很明确——高可用、强一致、能实时分析，具体包括用户账户（日均写 6 万条）、交易流水（日均 25 万 +）、实时风控。之前用的是 MySQL8 单机 + 主从复制，随着业务跑起来，有四个问题越来越突出：

1. 扩展性卡脖子：单机容量顶天 500GB，后续数据量上来就得手动分库分表，不仅开发要改路由逻辑，运维成本直接翻倍；

2. HTAP 能力缺失：OLTP 和 OLAP 得两套系统跑，ETL 链路绕来绕去，实时风控要的交易数据根本跟不上；

3. 高可用不靠谱：主从切换得人工介入，RTO 最少 5 分钟，要是赶上高峰期出问题，损失没法估；

4. 存储成本虚高：InnoDB 表空间压缩不了，100GB 业务数据实际占 130GB 磁盘，长期下来存储开销扛不住。

对比了一圈分布式数据库，TiDB 的“敏捷模式”一下子击中了我们——单节点就能起步，还保留完整的分布式能力，未来扩节点不用动业务。这种“先验证、再扩容”的节奏，跟我们技术路线完全匹配，所以借这次试用活动机会果断拉了测试环境搞一落地验证。

二、实战体验：从迁移到运维的 5 个核心场景

 1. 数据迁移：3 小时搞定 80GB 数据，零中断

这次迁移的是 MySQL 里的 80GB 业务数据，包含 20 张业务表、3 个索引，还有触发器这些，用的是 TiDB 的 DM 工具，整个过程 3 小时跑完，业务没断过，数据也没丢一条，比预期顺太多。

具体说几个关键细节：

• DM 会自动识别 MySQL 的自增主键、utf8mb4 字符集、datetime 类型，直接映射成 TiDB 兼容格式，不用手动改字段；

• 遇到不兼容的语法（比如 ON UPDATE CURRENT_TIMESTAMP），DM 会明确报告警，我们就改了 2 处建表语句，没花多少时间；

• 迁移完用 sync-diff-inspector 校验，数据一致性 100%，这一点比传统分库分表靠谱——之前试过同等数据量分库分表迁移，光准备就得 1 天，实际迁移 2-3 天，还得改应用层逻辑，对比下来 TiDB 这波效率直接拉满。

 2. MySQL 兼容性：Java 应用零改造连接

我们业务用的是 Java+MyBatis，本来还担心要改代码，结果连上去发现完全不用动——TiDB 对 MySQL 5.⁷⁄₈.0 的语法兼容度是真高。

常用的 LIMIT、JOIN、GROUP BY、子查询都支持，查元数据用 information_schema 也跟 MySQL 一样；唯一要注意的是存储过程和触发器不支持，但可以用 TMS 工具转成 Java 逻辑，刚好我们在推微服务，反而趁这个机会做了代码解耦，算是意外收获。

 3. 在线 DDL：大表加字段再也不用等半夜

之前 MySQL 里给大表加索引、改字段，都得等半夜业务低峰期，还得锁表，期间写入全阻塞，搞一次就提心吊胆。这次在 TiDB 上试了在线 DDL，直接刷新认知：

• 加字段（ADD COLUMN）秒级完成，读写完全没影响；

• 改字段类型（比如 INT 转 BIGINT）是后台异步跑的，业务侧完全感知不到；

• 加索引支持并发构建，压测看 P99 延迟波动不到 10%，以后迭代再也不用卡时间窗口了，开发效率至少提了 3 倍。

 4. 高可用验证：RTO<30s，数据零丢失

我们搭了敏捷模式集群，专门做了故障注入测试，结果比预期还稳：

• 故意宕掉主节点，服务自动切到备节点，全程没断连；

• 模拟网络分区，只要多数派节点还在，就能正常提供服务，数据是强一致的；

• 甚至试了磁盘损坏，Raft 多副本直接自动重建数据，最后校验也没丢任何一条，RPO=0，RTO 控制在 30 秒内，比 MySQL 主从异步复制强太多。

 5. TEM 运维：10 分钟部署集群，多集群管控更省心

作为 DBA，最烦的就是部署和多集群管理，TiDB 的 TEM 平台直接把运维效率提了一个档次：

• 部署单节点敏捷模式，用 TEM 的 Web 界面点几下，10 分钟就搞定，比手动用 tiup deploy 省了不少事；

• 现在测试环境 3 节点、生产环境 1 节点，都在 TEM 上统一管，监控、告警、备份策略一套配置就能同步，不用来回切换系统；

• 之前担心管控面出问题，特意测了主节点故障，备节点 15 秒就接管了，管控面也没断，这一点对我们运维来说太重要了。

三、总结：敏捷模式的核心价值

这次测试下来，TiDB 敏捷模式最让我们满意的是“平衡”——既没有因为“分布式”而增加额外的复杂度，也没有因为“单节点起步”而牺牲未来的扩展性。对中小规模业务来说，用接近单机 MySQL 的成本，就能解决扩展性、高可用、存储成本这些痛点，后续业务增长了，直接加节点就行，不用重构架构。

如果也有面临 MySQL 单机的瓶颈，又不想一步到位搞复杂的分布式架构，TiDB 敏捷模式真的可以试试，从迁移到运维，对 DBA 和开发都很友好，落地成本低，见效还快。