导语
丰巢作为国内规模领先的末端物流解决方案供应商，业务版图已深度覆盖快递末端配送、智能柜服务、广告及增值服务等多元领域。从消费者日常的寄件下单、取件操作，到快递员的派件流程管理，再到后台的支付结算对账，每一个核心业务环节的稳定运转，都离不开高可靠、高效率的数据库系统作为底层支撑。而 TiDB，正是丰巢在应对业务高速增长与技术难题时，破局突围的关键选择。
在 TiDB 社区活动武汉站的现场，丰巢数据库管理员谭品学带来了一场深度分享：从直面海量数据与高并发业务带来的技术挑战，到最终选定 TiDB 作为核心数据库；从基于 TiDB v4.0 的初步落地，到完成向 v7.5 版本的重大升级，多方位呈现这一过程中实现的性能跃升与效率突破。本文将详细介绍丰巢科技的实践路径。
作者：谭品学｜丰巢数据库管理员
百 TB 数据压顶：丰巢面临的核心技术挑战
丰巢的业务场景中，数据流转与业务需求紧密交织。消费者通过微信、支付宝、丰巢官网等多渠道发起寄件下单请求，快递员使用丰巢巴枪完成派件操作，柜机与后台系统实时交互实现收寄管理，同时线上支付、订单打印、对账结算等环节环环相扣。这一过程中，数据量的增长速度极为惊人。
据谭品学介绍，丰巢派件相关数据量已达到几十TB 以上，支付业务数据量也已上几十TB，且这还是经过常年持续归档后的数据规模，整体在线运行数据量早已突破百TB级别。不仅如此，业务高峰期的并发压力更是严峻——派件收件环节会产生数以万计的并发请求，用户扫码、快递员投件等每一个微小操作，都会转化为一次数据库访问请求，对系统的响应速度和稳定性提出了极高要求。
在数据一致性方面，支付业务是绝对的“生命线”。每一笔交易数据都必须准确无误，任何数据丢失或不一致都可能引发财务纠纷与用户信任危机。此外，随着业务的长期发展，大量历史数据需要在线保存以满足查询与合规需求，大存储需求成为丰巢数据库架构必须面对的长期挑战。
MySQL 架构痛点日益凸显
然而，丰巢最初使用的 MySQL 架构，在应对这些需求时逐渐显露出诸多痛点。
首先是水平扩展困难，MySQL单机架构的磁盘容量存在明显上限，丰巢部分 MySQL 实例的磁盘容量已超过 几十TB，实时数据常年维持在TB以上，逼近性能严重衰退的临界点，且无法通过简单增加服务器实现高效扩展。
其次，读写分离在高并发场景下暴露出短板，主从复制架构会导致数据延迟超过秒级甚至分钟级别，若将读写操作全部集中在主库，又会面临性能瓶颈风险。更关键的是，当采用分库分表方案实现分布式部署时，数据一致性难以保障，给业务带来了潜在隐患。
与此同时，分库分表的维护成本“特别高” 。假设需要对分库分表的某一张表做一个 DDL 的变更，则需要把所有的表全部做一次变更，也就是说如果分了 100 张表，就要执行 100 次 DDL，在线 DDL 处理可能会影响业务连续性。这种操作带来了巨大的风险和运维压力。运维团队既不能分批执行，又担心一次性全部执行会瞬间“把整个数据库给打垮”。更糟糕的是，分库分表策略在丰巢的订单中心实践中还遭遇了严重的数据倾斜。在早期的改造中，发现设置了分片键后，数据分布极不均匀——某张分表可能承载 90% 的数据，其余分表仅占 10%，这使得分库分表的设计完全失效。
在探索解决方案的早期，丰巢也曾短暂尝试过 Mycat 这样的中间件方案，但 Mycat 的配置和维护难度很高，并且在较早停止了维护，最终丰巢放弃了这一技术路线。
TiDB 的全链路应用与架构优势
基于 MySQL的种种局限，以及对强一致性、高并发和海量存储的迫切需求，丰巢在七八年前就做出了一个具有前瞻性的决定——选择 TiDB 作为解决方案。TiDB 作为一款开源的分布式数据库 ，其核心特性精准地解决了 MySQL 的全部痛点。
其一，TiDB 具备无缝水平扩展能力，只要资源允许，就能无限拓展存储与计算能力，上 TB 的数据量在 TiDB 架构中仍处于健康运行水平，彻底解决了 MySQL 单机扩展的难题。
其二，TiDB 通过 Raft 协议保证数据强一致性，同时实现故障自动恢复，无需人工干预即可确保服务高可用，这对于需要 7×24 小时稳定运行的物流系统至关重要。
其三， TiDB 强兼容 MySQL 生态，丰巢通过 SQL 回放测试——将 MySQL 中运行的 SQL 指纹与真实 SQL 在 TiDB 中重放，仅需针对少量不兼容 SQL 进行优化，即可完成迁移，大幅降低了升级成本与技术风险。
此外，TiDB 的 HTAP（实时分析与在线事务处理）架构也突破了 MySQL 在混合工作负载下的性能瓶颈。
在实际业务应用中，TiDB 的价值得到了充分体现。从快递员派件时产生的派件数据，到用户取件时依赖的取件码信息，再到订单数据、用户数据与支付流水，这些核心业务数据均存储于 TiDB 中。
TiDB 应用收益：架构简化与业务高峰期的从容
引入 TiDB 为丰巢带来了显著的架构简化和业务收益。在架构简化方面，TiDB 内置的分布式事务和一致性协议，减少了对 Mycat 这类传统中间件的依赖。同时，TiDB 实现存储与计算分离，通过 TiKV（存储层）与 TiDB Server（计算层）的紧密配合，实现统一架构管理，运维复杂度大幅下降。
最关键的是其弹性扩展能力。TiDB 的水平扩展能力使得系统在面对流量波动时可以更加灵活地进行资源调整，极大简化了运维复杂度。传统 MySQL 架构难以灵活应对“双11”的流量高峰，而使用 TiDB，丰巢的应对策略则显得游刃有余。作为物流行业，丰巢在业务高峰期（如“双 11”、“618”）会扩容 TiDB Server（计算节点）。例如，平时运行 10 个 TiDB Server 节点，在“双 11”时可能会再加 5 个节点，然后再备 5 个节点，以扛住高峰期流量。这种在计算层的快速弹性扩容，极大地提高了系统的负载能力。
在业务收益方面，TiDB 的分布式架构显著提升了数据处理能力，支持了更大规模的数据量和更复杂的查询。同时，TiDB 的高可用性和自动化运维特性降低了运维成本。相较于分库分表需要重复执行 DDL 的噩梦，使用 TiDB时，运维人员可直接在平台上执行 DDL，内部自动完成操作，无需担心性能问题以及业务连续性。此外，TiDB 的三副本机制与故障自愈能力，让丰巢在故障演练中充分验证了系统稳定性，即使单个节点故障，也不会影响业务正常运行，大幅减少了故障停机时间。
关键升级：从 TiDB v4.0 到 v7.5 的性能飞跃
在稳定使用 TiDB 多年后，丰巢决定将 TiDB 版本从 v4 升级至 v7.5 LTS，这一升级具有强烈的必要性——TiDB V4已达到 EOL（生命周期结束）阶段，面临安全隐患与功能局限，无法满足业务发展需求。而 TiDB V7.5 LTS 在性能、稳定性与成本效益上均有显著优化。
丰巢的升级目标明确：平稳过渡至 TiDB v7.5 LTS，实现业务零感知过渡，确保数据一致性，并借此提升系统性能与业务价值，为未来发展奠定坚实的技术基础。为了实现这一目标，丰巢团队在升级前进行了极其周密和详尽的核心验证工作。
在 SQL 兼容性方面，重点关注 DDL 与 DML 语句语法变化，通过自动化测试工具与人工审查结合，覆盖 99% 以上核心 SQL 场景；性能回归验证中，采用 TPC-C 基准测试模型，对比关键 SQL 执行效率，重点监测查询响应时间与吞吐量，确保升级后性能提升至少 10%；高负载稳定性验证则模拟生产环境高并发压力，参考 Gartner 稳定性评估模型，保障系统在持续高负载下仍能达到 99.99% 的可用性标准。在数据校验环节，丰巢自研了一套数据比对工具帮助更快的进行数据分析。
升级后：77% 的延迟降低与数倍的效率提升
从 TiDB v4.0到 TiDB v7.5 LTS 的升级，为丰巢带来了极其直观和可观的收益。
首先是查询性能的巨大飞跃。监控图表清晰地显示，TiDB 的执行耗时（P99）从 224ms 大幅降低至 28.9ms，延迟降低了 77%。需要特别强调的是，这是在没有改任何业务代码的情况下，直接实现的性能优化。其次是存储成本的显著优化。升级后，存储占用率缩小了 28%，在提升存储数据量的同时降低了存储成本。此外，其他功能也得到了全方位的提升：
- 数据备份速度和稳定性提升 5~6 倍。在 v4.0 时，备份一次需要十个小时左右，而升级到 v7.5 后，基本上一个多小时就能备份完。
- 增加索引速度提升 2~3 倍。在 v4.0 时，数据量大的表加索引可能耗时会达到七八天之久，升级到 v7.5 后仅需一两天即可完成。
ANALYZE执行速度提升 10 倍以上。ANALYZE（收集统计信息）对丰巢来说“很关键”。因为如果统计信息不对称，会导致优化器无法选择正确的索引，触发全表扫描。v7.5 不仅收集速度更快，其执行记录也有优化，方便自建系统进行监控，可有效避免全表扫描问题，保障数据库稳定运行。- 主备同步延迟降至毫秒级。丰巢之前使用 Binlog 同步，其延迟大约在七八秒左右。升级后切换到 TiCDC，延迟降至毫秒级。并且 TiCDC 在推送到 Kafka 等下游时，支持按分区推送，有助于提升下游数仓的消费速度。
结语
回顾从 MySQL 的重重困境到 TiDB 的性能飞跃，丰巢科技认为，TiDB 通过其存算分离分布式架构，实现了性能与可扩展性的显著提升。其多副本和故障自动恢复功能，提供了比 MySQL 更高的数据安全性和服务可用性。同时，TiDB 保持了与MySQL的良好兼容性，使得迁移和生态融合更加平滑。
正是这些特性，使得从 MySQL 到 TiDB 的演进，不仅是一次技术架构的升级，更是对丰巢全链路核心业务的一次成功重塑。TiDB 为丰巢提供了稳定、高效且可灵活扩展的数据支持，确保了其在海量数据和高并发冲击下的业务连续性。
基于这一成功的实践，丰巢对于 TiDB 的未来也有着明确期待：持续优化性能，确保系统在高并发场景下始终稳定高效；拓展生态系统，实现与更多外部工具的兼容，减少业务迁移与适配成本；完善平台接口，为企业平台化发展与二次开发提供更丰富的支持。