一、前言：一家“小而杂”的零售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只留历史归档