一、前言
本次体验主要是模拟测试公司业务在TiDB 敏捷模式和MySQL数据库下的优劣势。当前业务主要包括：用户账户管理（日均写入约6万条）、交易流水记录（日均25万+）、以及基于交易行为的实时风险识别。业务初期数据规模较小（总数据量<100GB），但对数据库的高可用、强一致性、实时分析能力有明确要求。
过去使用 MySQL 5.7 单机 + 主从复制架构，随着业务增长逐渐暴露出以下问题：
- 扩展性差：一旦数据量超过单机容量（约 500GB），必须手动分库分表，开发和运维成本剧增；
- HTAP 能力缺失：OLTP 与 OLAP 需要两套系统，ETL 链路复杂，实时性差；
- 高可用依赖外部方案：主从切换需人工介入，RTO 通常在 5 分钟以上；
- 存储成本高：MySQL InnoDB 表空间无法有效压缩，100GB 业务数据实际占用约 130GB 磁盘。
在评估多个分布式数据库方案后，关注到平凯数据库推出的“敏捷模式”——支持单节点起步、保留完整分布式能力、未来可无缝扩展。这与公司“小步快跑、快速验证、平滑演进”的技术路线高度契合，因此决定参与试用。
通过模拟完整验证了迁移、兼容性、压缩、高可用、扩展性等核心能力。整体体验超出预期：用接近 MySQL 单机的成本，获得了分布式数据库的完整能力栈。
二、平凯数据库敏捷模式功能体验
1. 数据迁移体验：平滑、高效、低风险
将 MySQL 5.7 中的 80GB 业务数据（含 20 张表、3 个索引、触发器等）迁移至 TiDB 敏捷模式。整个过程耗时约 3 小时，零数据丢失、零业务中断。
- DM 自动识别 MySQL 的自增主键、字符集（utf8mb4）、时间类型（datetime）等，并映射为 TiDB 兼容格式；
- 对于不兼容语法（如
ON UPDATE CURRENT_TIMESTAMP），DM 提供明确告警，仅需微调 2 处建表语句； - 迁移后通过 sync-diff-inspector 工具校验，数据一致性达 100%。
对比：若采用传统 MySQL 分库分表方案，同等数据量迁移需 2–3 天，且需改造应用层路由逻辑。
2. MySQL 兼容性：开箱即用
TiDB 对 MySQL 5.7/8.0 语法兼容性极高。我们的 Java 应用（基于 MyBatis）无需修改一行代码即可连接 TiDB。
- 支持
LIMIT,JOIN,GROUP BY, 子查询等常用语法； - 支持
information_schema查询元数据； - 唯一需注意的是：不支持存储过程、触发器（但可通过 TMS 工具自动转为 Java 逻辑，适合微服务架构）。
3. 在线 DDL 操作：开发效率倍增
TiDB 支持无锁在线 DDL，极大提升迭代速度：
ADD COLUMN：秒级完成，不影响读写；MODIFY COLUMN（如INT → BIGINT）：后台异步执行，业务无感知；ADD INDEX：支持并发构建，P99 延迟波动 < 10%。
对比：MySQL 在大表上加索引需锁表，期间写入阻塞。
4. 高可用/容灾：RPO=0，RTO<30s
搭建敏捷模式集群，模拟以下故障：
- 节点宕机：服务自动切换；
- 网络分区：多数派节点仍可提供服务，数据强一致；
- 磁盘损坏：通过 Raft 多副本自动重建，数据零丢失。
通过 sysbench oltp_read_write 持续压测 + 故障注入，验证了数据一致性无损，远优于 MySQL 主从异步复制。
5. TEM 易用性：运维效率革命
- 部署：通过 TEM Web 界面，10 分钟内完成单节点敏捷模式部署，比手动
tiup cluster deploy更直观； - 多集群管控：同时管理测试集群（3节点）和生产集群（1节点），支持统一监控、告警、备份策略；
- 高可用：验证主节点故障后，备节点 15s 内接管服务，管控面持续可用。
三、平凯数据库敏捷模式优势 & 体验总结
1. 个人认为在以下场景会建议用敏捷模式
- 金融科技：风控、支付、账户系统，需高可用 + 实时分析；
- SaaS 初创企业：客户量不确定，需低成本启动 + 弹性扩展；
- 政企信创项目：要求国产化、高安全，又受限于初期预算；
- 传统 MySQL 替换场景：希望避免分库分表，一步到位分布式架构。
2. 敏捷模式整体体验总结
作为数据库开发人员，TiDB 敏捷模式给我最大的感受是：“小而全，轻而强”。
- 1 台服务器即可跑起完整 TiDB 栈；
- HTAP、高可用、在线 DDL、备份恢复等企业级能力一个不少；
- TEM 让运维从“命令行苦力”变为“可视化操作”；
- 性能、压缩、扩展性全面优于 MySQL 单机。
让 DBA 告别分库分表、熬夜 DDL 和漫长的夜间批处理，是真正能给老板省钱、让自己睡安稳觉的方案。