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

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

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

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

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

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

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

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

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

这次迁移的是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这波效率直接拉满。

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

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

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

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

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

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

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