数据库升级最难的部分，通常不是找到一款性能更强的产品，而是在业务仍高速运行时，判断什么时候必须换、先换哪些系统，以及如何让研发和运维团队平稳过渡。
近日，在 TiDB 社区活动青岛站，青岛市外贸企业数字化转型赋能中心分享了从 MySQL 性能拐点，到交易、分析与运维一体化的新底座实践，提出了数据库升级不是一次性推倒重来，而是在增长拐点前完成一次低侵入、可验证、分阶段的架构换道。
刘建飞｜青岛市外贸赋能中心数据架构负责人
增长把旧架构推到拐点
青岛市外贸企业数字化转型赋能中心是在全球海关通关无纸化改革的浪潮中应运而生，以报关 SaaS 起步，历经从 IT 到 DT，从大数据到人工智能的信息革命，深耕外贸服务领域，对相关业态中的岗位进行拆解、集成和协同，构建起国内首创、国际领先的数字化供应链管理平台。
2017 年，关务产品的报关单量已达到千万单/年，平台服务的活跃企业超过 30 万家；此后，物流结算、金融决策和企业数字化诊断等业务持续加入，数据不再只是报关流程的记录，也开始成为经营分析与金融风控的重要输入。
早期系统采用典型的 LNMP 架构，数据库使用 MySQL 5.6 主从模式。2023 年启动物流业务研发后，应用与数据库版本都做过一轮升级，但到 2024 年、2025 年，业务规模、数据量和并发量继续增长，集中式架构的边界开始集中暴露。团队观察到，部分 InnoDB 大表在接近或突破 2000 万行后，索引更新、分页、聚合与联表查询的成本明显上升；单机磁盘、I/O 与 CPU 又难以横向扩展，扩容始终带着被动补救的意味。
分区分表曾是自然的备选方案，却没有真正消除复杂度。分区键对主键和唯一索引的约束、不命中分区键时的扫描代价、外键限制以及全局自增 ID 等问题，会把数据库的压力转移到代码、规则和运维流程中。与此同时，所有写入仍集中在主库，从库延迟限制了实时交易与实时大盘的使用；报表和聚合若直接压向业务库，又可能拖慢在线链路。另建数仓虽然能够隔离分析负载，却增加了同步链路、组件数量和维护成本，数据时效也难以满足实时需求。
这意味着问题已经不再是某条 SQL 或某个参数，而是交易、分析、容量、高可用与运维复杂度同时触顶。继续局部优化，只会延后决策，并让未来迁移背上更多技术债。
选型不是比功能表，而是计算迁移总成本
2025 年初，团队启动数据库选型。最先验证的仍是硬件升级与参数优化，因为这条路改动最小；但测试结果显示，它无法解决写入瓶颈和大表的长期增长问题。随后，团队对 Oracle、PostgreSQL、OceanBase 以及多种云数据库方案进行了比较。最终没有采纳，并不意味着这些产品缺少能力，而是授权成本、运维复杂度、技术栈切换压力、长期容量与投入产出比等因素，与当时的团队条件和业务目标不完全匹配。
TiDB 进入候选后，团队首先关注的是 MySQL 兼容性。更换核心数据库牵动产品、研发、测试和运维，真正昂贵的往往不是软件本身，而是 SQL、业务逻辑、工具链和人员能力的整体迁移。TiDB 对 MySQL 协议、语法与生态工具的兼容，让团队能够尽量复用现有代码与使用习惯，把架构升级的风险控制在可接受范围内。
其次才是分布式架构本身：计算与存储分离，TiDB 计算层可按并发扩展，TiKV 通过 Region 自动分片与均衡数据；分布式事务为跨节点、跨分片的一致性提供保障；TiFlash 列存副本让同一份逻辑数据同时服务联机交易与实时分析。再加上基于 Prometheus 和 Grafana 的监控体系，以及覆盖部署、迁移、扩缩容的工具链，团队看到的不是单个性能指标，而是一套能够持续运营的数据底座。
从两套核心系统起步，让新架构先在生产中证明自己
青岛市外贸赋能中心没有把所有 MySQL 系统一次性迁走。当前已迁移的重点包括物流系统和“易海融”金融平台，两者都同时面对高并发交易、海量数据存储与实时分析需求，最能检验新架构的价值。仍适合 MySQL 的小规模业务则继续保留，形成两种数据库并行、按场景选择的格局。
现有 TiDB 集群通过负载均衡提供统一入口，计算层部署 3 个 TiDB 节点，管控层部署 3 个 PD 节点，存储层部署 3 个 TiKV 节点，并配置 1 个 TiFlash 节点承接部分实时报表与聚合统计。在线交易主要走 TiKV 行存，分析查询由 TiFlash 分担；数据不必先复制到另一套分析系统，链路因而更短。随着后续实时分析需求增加，团队计划继续扩展 TiFlash 能力。
这种起步方式的关键，是把最强诉求与最可验证场景放在一起：先让两个核心系统在真实负载中证明兼容性、性能与稳定性，再决定后续迁移节奏。架构升级由此从“大切换”变成了一系列可评估的小决策。
真正有说服力的，是日常工作被改变
分享中最直观的例子来自一张历史大表。过去给这张表增加字段，常常需要十几分钟，极端情况下接近 30 分钟，发布前必须专门预留操作窗口。团队把数据库迁到 TiDB 环境后再次测试，同类操作缩短到秒级。对研发而言，这不是单纯的跑分提升，而是一次常规变更不再占用漫长等待时间。
查询体验也出现了类似变化。部分过去需要十几秒甚至二十几秒的复杂 SQL，在迁移后进入秒级或毫秒级范围；原有 JOIN 查询无需大幅改写即可获得更快响应。对业务侧来说，直接感受是查询、大盘与统计更及时；对研发侧来说，则意味着减少为了绕开数据库限制而编写的拆分与适配逻辑。
运维的变化同样重要。多套 MySQL 主从与分片组件逐步收敛后，监控、容量、节点状态和慢 SQL 能够在统一平台查看。根据团队在当前实践周期内的统计与观察，部分实时数据链路从分钟级缩短到秒级，人工干预率降低 90% 以上，研发迭代效率明显提升；生产环境运行时间尚不足一年，但在这一观察窗口内未发生重大集群故障。这些数字应放在具体业务范围内理解，却已经足以说明：新底座的价值不只体现在峰值性能，更体现在重复劳动、故障点和等待时间的减少。
不是所有业务都需要分布式数据库
这次实践还有一个值得保留的判断：TiDB 不是 MySQL 的无差别替代品。数据量持续增长、存在分库分表压力、需要兼顾高并发交易与实时分析，或对一致性、高可用和容灾有强诉求的核心系统，更能发挥分布式架构的优势。海量日志、流水、历史数据与跨节点聚合统计，也属于较合适的场景。
相反，数据量长期稳定、低并发、结构简单的小系统，使用单机 MySQL 往往更经济。青岛市外贸赋能中心因此保留 MySQL 与 TiDB 混合使用，并按业务规模、增长速度、负载类型和保障等级制定迁移规则。后续计划也遵循同一逻辑：逐步迁移并统一规范，扩展 TiFlash 分析能力，同时评估主备双中心容灾，而不是为了技术统一而强行统一。
把换库变成一次面向增长的组织升级
回看整个过程，青岛市外贸赋能中心完成的并不只是从 MySQL 到 TiDB 的产品替换。团队重新回答了三个更基础的问题：什么样的增长值得提前换架构，什么样的能力应该下沉给数据库，什么样的业务仍应保留更轻量的选择。
数据库真正“撑不住”的那一天，往往已经是迁移最被动、改造最昂贵的时候。更好的时间点，是性能拐点已经出现，但代码和中间件尚未与旧架构深度绑定；业务有足够强的需求，同时又允许从少数核心系统开始验证。以兼容性降低切换成本，以分布式能力消化未来增长，以 HTAP 缩短实时数据链路，再以工具与监控把能力交给团队日常使用。