一家“小而杂”的零售 SaaS 公司，为什么把数据库从 MySQL “搬”上平凯数据库（TiDB 企业版）敏捷模式？

作者： TiDBer_AleUf12Q 原文来源：https://tidb.net/blog/5271be60

一、前言：一家“小而杂”的零售 SaaS 公司，为什么把数据库“搬”上 TiDB 敏捷模式？

1. 企业 & 行业 & 业务

• 公司规模：200 人，做零售 SaaS，给连锁便利店提供 POS+ 库存 + 会员小程序。

• 数据特点：每天 4000 万笔流水，高峰期早上 7-9 点“早餐档”QPS 瞬间拉到 2.5w；客单价低、笔数多，索引热点极其明显。

2. 目前遇到的数据库挑战

• MySQL 8.0 主从，三节点 MGR，每天上午“锁等待”报警 >300 条；高峰期 CPU 90%+，慢查询把前端结账卡成 PPT。

• 业务要做“实时折扣”：根据过去 30 分钟销量动态改价，MySQL 扛不住在线聚合，只能 T+1，运营天天吐槽“折扣永远慢半拍”。

3. 参加活动的原因

平凯搞“敏捷模式”体验营，承诺“两小时交付、三节点起步、K8s 一键扩”，还送 TEM 控制台。正好公司刚买了三台裸金属想试水，就报名了。

二、平凯数据库敏捷模式功能体验（全程 TEM 控制台 + 点鼠标）

1. 数据迁移体验

• 工具：DM 6.0，TEM 里直接“新建迁移任务”，填 MySQL 主库 IP、Binlog 位点，下一步下一步即可。

• 平滑度：460GB 全量 +22GB 增量，全程 0 锁表；切流瞬间最大延迟 190ms，业务无感知。

• 小插曲：初期 Binlog checksum 报错，把 MySQL 参数binlog_checksum=CRC32改成NONE解决，DM 官方文档已提示。

2. MySQL 兼容性

• 业务代码零改动：JDBCurl 从mysql://换成tidb://，日期、分页、JSON 函数全通。

• 唯一踩坑：原来用SELECT ... FOR UPDATE NOWAIT，TiDB 默认不支持，加@@tidb_enable_noop_functions=1绕过，应用层改一行配置即可。

三、平凯数据库敏捷模式优势 & 体验总结

1. 哪些场景强烈建议用敏捷模式

• 零售 / 餐饮 / 酒店等“早晚高峰明显、需要实时报表”的 SaaS。

• 业务在 MySQL 上遇到“索引热点 + 锁等待”死循环，又不敢上大版本分库。

• 团队缺专职 DBA，开发想“点点鼠标”就把集群扩了、备份做了、告警接了。

2. 整体体验一句话

“两小时上线、半天迁移、一周见效”——TiDB 敏捷模式把分布式数据库的门槛拉到 RDS 级别，却保留了横向扩展和实时 AP 的硬核能力；对中小体量、快速成长的业务来说，它就是“MySQL 瓶颈终结者”。我们下一步已经把全年 KPI 写好了：让 TiDB 承载 80% 核心流水，MySQL 只留历史归档