背景：我们一套跑了五年的订单分析系统，主库是 MySQL 8.0，平时扛交易，月底还要跑 T+1 报表。一次月底大查询把从库 CPU 打到 100%，复制延迟一度飙到 47 秒，运营看板直接瘫痪。那一刻我意识到，把 OLTP 和重分析塞在同一套实例里，迟早出事。
为什么盯上 TiDB
当时评估了三个方向：给 MySQL 加只读从库专门跑报表、上 ClickHouse 做分析、换 TiDB。前两者都要双写或同步，链路长、数据一致性难保证。TiDB 的卖点是 HTAP——同一份存储，行存（TiKV）扛交易、列存（TiFlash）扛分析，SQL 层自动路由，应用基本无感。这对我们这种"既要交易又要分析"的库很有诱惑力。
兼容性摸底，先打脸
官方说兼容 MySQL 协议，我们还是把生产慢查询日志捞了 3000 条 SQL 跑了一遍兼容性扫描。结果三类坑最扎手：
- 存储过程与函数：我们有 12 个老存储过程，TiDB 虽支持但不完全等价，其中一个用到了
GROUP_CONCAT的长度上限差异，结果被截断； - 自增 ID 语义：MySQL 是连续递增，TiDB 早期版本用
AUTO_RANDOM或跳号的AUTO_INCREMENT，依赖连续 ID 的下游对账逻辑直接报错； - 隔离级别细节：我们的报表用了
REPEATABLE READ下的某些快照读假设，TiDB 的 MVCC 行为在长事务下表现不同，出现"读到了中间态"的脏读错觉。
兼容性不是"能连上"就行，是把业务里那些隐含假设全翻出来校验。
收益与风险的量化对比
| 维度 | MySQL 8.0 | TiDB 7.x |
|---|---|---|
| 月底大查询耗时 | 38 分钟（拖垮主库） | 4 分 12 秒（走 TiFlash） |
| 从库复制延迟峰值 | 47 秒 | 行存/列存内部同步，无外部延迟 |
| 单实例容量上限 | 约 2TB 吃力 | 弹性扩到 20TB+ 实测 |
| 运维复杂度 | 低 | 高（PD/TiKV/TiFlash 多组件） |
迁移不是一键切换
我们选了 DM（Data Migration）做全量 + 增量同步，先让 TiDB 追平 MySQL，再切读流量。关键一步是"双写校验"：在应用层用影子写入，把同一笔订单同时落 MySQL 和 TiDB，跑对账任务比对行数和关键字段。前两周每天凌晨比对，差异从最初的 127 行收敛到 0。切读流量是按表灰度的，先切了只读的报表库，观察三天无异常，再切交易读。
踩到的真实坑
- 热点：订单表按
order_id自增，写入全打在一个 Region 上，QPS 上到 8000 时 Region 频繁分裂，延迟抖动。改成AUTO_RANDOM打散后稳定； - TiFlash 同步延迟：大批量导入时列存落后行存 2 分钟，报表读到旧数据。我们给报表加了一道"列存延迟阈值"判断，超阈值就回退行存执行；
- 资源成本：三组件加副本，机器数比 MySQL 翻了 4 倍，账单让老板皱眉。
迁移后的容量与运维账单
迁移不是终点。TiDB 上线后我们重做了容量规划——按当前增速，行存预计 14 个月到 15TB，提前和运维约好扩容窗口。加 TiKV 节点是在线扩、不停服，这点比 MySQL 分库省心。运维上最大的变化是"要看的面板多了"：PD 的调度延迟、TiKV 的 Region 均衡、TiFlash 的同步延迟，三个组件各有健康度指标。我们给新人写了排查手册，第一页就写"复制延迟先看 TiFlash 而非传统从库"，避免惯性思维。月度机器从 MySQL 的 3 台升到 9 台，但省下了为报表单独养的 OLAP 集群，整体成本持平。技术选型最终要落在这张账单上，不能只看特性对比。
小结
TiDB 的 HTAP 确实解决了"分析拖垮交易"的痛点，月底报表从 38 分钟降到 4 分钟，且不再影响主库。但它不是银弹：兼容性要逐条验证、热点要主动打散、运维成本和机器开销明显更高。我的建议是，只有当 OLTP 和重分析真正耦合、且单机/主从方案已经触顶时，才值得上 TiDB。为了 HTAP 而 HTAP，大概率会背着一套更重的系统，却没用上它的核心能力。