一、 业务飞速狂奔：亿级订单量呼唤新一代数据库
老百姓大药房是国内头部医药零售连锁企业之一，业务覆盖全国 18 个以上省级市场，门店数量超过 15000 家，经营品规超过 25000 种，已形成门店、电商、小程序一体化的全渠道运营体系。
后端的 ERP 核心系统面临实打实的压力：
- 高频读写与海量累积：门店销售、库存扣减、调拨补货等动作持续发生，导致老百姓大药房的 ERP 订单量、库存变动记录以及核心表数据量统统飙升至亿级规模，历史数据更是达到 TB 级别。
- 弹性与混合负载的考验：既要稳定承载日常高频交易以及大促期间的波动流量，又要满足业务部门对报表分析、数据导出等经营决策的需求，单一系统很难同时兼顾。
早期的 ERP 系统以 Oracle 为主、MySQL 为辅。面对上万家门店的业务扩张需求，老百姓大药房对新一代数据库提出了三大核心诉求：
- 成本低：打破原有老旧架构的高昂授权与硬件成本壁垒。
- 性能佳：必须能够满足万店规模下，亿级核心数据的高效读写。
- 高效运维：需要具备完善的监控体系，方便集群的扩容与缩容，以快速响应业务的扩张节奏。
最终，老百姓大药房将目光投向了原生分布式数据库TiDB。
二、 核心架构升级：从“试水读库”到“全面接管读写”
为了平稳地支撑业务并完成底层架构的替换，老百姓大药房 ERP 团队规划了稳扎稳打的 TiDB 落地实践路线。
第一阶段：只读试水，承接聚合查询
在新 ERP 建设前期，团队采用了“MySQL 为主 + TiDB 为辅”的综合策略。此阶段，核心的写入与点查流量仍由 MySQL 集群承接。团队在 IDC 机房内部署了 TiDB，通过 DM 工具实时同步数据，专门用于承接聚合查询。在这一阶段，TiDB 能够方便地进行跨库查询，支撑部分数据分析业务，并极大地优化了数据导出需求。
第二阶段：整体上云并升级，引入 TiFlash
由于早期 IDC 机房偶发的稳定性问题，团队决定将系统整体迁移至腾讯云。MySQL 集群被替换为腾讯云上的 TiDB 集群。同时，云上的 TiDB 集群升级至了 v7.5 版本，并正式引入了 TiFlash 列存节点来增强分析能力。这次升级带来了立竿见影的性能提升，系统资源消耗也成倍降低。
第三阶段：卸下历史包袱，TiDB 完全承接读写
随着云上 TiDB 集群展现出强大的性能余量与高可靠性，团队果断摒弃了复杂的双库并行架构。去除了所有的 MySQL 集群及 DM 数据同步链路，将写入、点查与聚合查询全部交由 TiDB 承接。
在最新的架构中，为了做到业务资源的极致隔离，存储层被精细化拆分为四个独立的 TiDB 集群：公共 TiDB 集群、商品 TiDB 集群、库存 TiDB 集群以及交易 TiDB 集群。
三、 不只降本 50%：为什么 TiDB 适合医药零售 EPR 场景
将底层存储彻底切换为 TiDB 分布式架构后，老百姓大药房不仅完美承接了万店规模的数据并发，更在降本增效层面获得了四大核心收益：
- 成本收益：通过减少数据库实例与中间件组件的部署，MySQL 实例几乎降为了 0。同时，TiDB Server 节点数量从 27 个大幅下降为 9 个，系统整体成本约降低了 52%。
- 系统稳定性：得益于 TiDB 的多副本存储与自动故障恢复机制，架构彻底避免了单节点故障对业务的影响。系统运行中的“毛刺”大幅减少，系统可用性成功提升至 99.99% 级别。
- 研发效率：TiDB 原生的自动分片能力和对跨节点 SQL 查询的完美支持，让研发团队无需在代码层维护繁琐的分库分表逻辑。据评估，数据库相关的开发工作量预计减少了超 10%。
- 运维效率：通过集群的统一管理，支持在线灵活扩容与自动调度。DBA 免去了熬夜盯盘做 DDL 变更的痛苦，数据库运维工作量预计降低了约 30%。
四、选择对的数据底座，拥抱 HTAP + AI 新可能
老百姓大药房的实践，是医药零售行业数字化演进的一个缩影。当查询、分析、导出和交易可以在更统一的底座上协同运行后，ERP 不再只是被动地“把业务流程跑通”，而是开始灵活支持经营决策。在夯实了核心 ERP 的交易底座后，老百姓大药房对 TiDB 的应用充满了期待，未来将继续探索 TiDB 在 HTAP 实时报表上的潜力，调研平凯数据库云服务，以及 AI Agent 记忆数据存储等前沿场景。
用分布式架构支撑门店增长，用统一底座减少系统复杂度，用高可用保障交易连续性。 这是 TiDB 作为新一代数据库给企业扩张带来的底层技术力量。