TiDB海量数据无感扩容实战技巧与容量优化方案

时间：2026-08-21 16:09

对于任何一家业务高速发展的企业而言，如何应对流量高峰带来的冲击，始终是技术团队必须直面的关键挑战。面对海量数据场景，数据库系统与业务团队都希望实现“无感扩容”，但常见的分库分表方案在扩容效率、运维复杂度以及数据一致性方面，往往难以完全满足企业需求。行业亟需一种高性能、易使用的全新数据库解决方案，从根

业务需求始终是推动技术创新的重要力量。近年来，由 PingCAP 开发的 TiDB 分布式数据库迅速崭露头角，在海量数据处理和弹性扩展领域展现出明显优势。也正是在这样的背景下，2020 年初，京东智联云携手 PingCAP，基于 TiDB 打造了云端分布式数据库——Cloud-TiDB。

11 月 26 日，京东智联云与英特尔联合举办了主题为“突破极限，TiDB 在京东智联云的技术架构与实践”的线上直播活动。直播邀请到_京东智联云云产品研发部架构师葛集斌老师，以及 PingCAP TiDB 生态技术布道专家戚铮老师_分别进行分享，希望借此帮助更多企业与开发者打开思路，在分库分表之外找到新的数据库选型方案，并进一步了解如何在生产环境中真正发挥 TiDB 的价值。

本文内容整理自本场直播分享，并进行了适当编辑。

一、TiDB在京东智联云的技术架构与实践

直播的第一部分，葛老师重点分析了京东智联云为何选择 TiDB 数据库，并详细介绍了 TiDB 在京东智联云上的技术架构设计与生态实践。

1，TiDB数据库希望解决哪些问题

在当前大数据时代，传统单机数据库的局限性愈发明显。对于一家快速成长的企业来说，随着业务规模持续扩大，数据量也会同步增长，单机数据库很快就会面临多方面瓶颈：

单表、单库数据规模过大；
单机存储容量触及上限；
单机计算与处理能力达到瓶颈。

读取延迟持续升高，存储需求不断增加，同时写入性能难以继续扩展。
如果还想进一步提升数据库性能，传统思路通常是实施分库分表，但分库分表方案本身也存在不少天然限制。

在高可用性方面，MySQL 往往需要依赖外部组件配合处理。
MySQL 的故障检测、主从角色判断与故障转移通常都需要额外定制策略。
异步复制和半同步复制并不具备强一致性，存在一定的数据丢失风险。
此外，MySQL 在 OLAP 数据处理方面能力相对有限，若有数据分析需求，通常还需要通过 ETL 将数据同步到外部分析系统。以上这些问题，都是传统数据库架构在现实应用中经常遇到的瓶颈。TiDB 的诞生，正是为了应对这些传统数据库常见难题，希望从架构层面突破单机数据库的能力边界。

从技术实现来看，TiDB 数据库是如何解决上述问题的？首先需要明确，TiDB 不同于传统单机数据库架构，它是一款真正意义上的分布式数据库。TiDB 采用计算与存储分离的架构设计，具备水平线性扩展能力，同时提供强一致性、高可用性和自动故障恢复能力，还支持实时分析处理，并高度兼容 MySQL 协议。整体架构上，TiDB 主要由 TiDB Server、分布式存储层以及 PD 三大部分组成：

TiDB Server 兼容 MySQL 协议，并支持水平扩展，因此用户可以将 TiDB 作为 MySQL 数据库来使用。
TiDB 存储层 TiKV 是分布式 KV 存储引擎，支持线性扩展，并借助多副本机制和 Raft 协议来保障强一致性。TiKV 内部还会划分为多个 region，并以 region 为基本单位进行管理。数据分布在不同 TiKV 节点上，节点可以按需横向扩容。
PD 负责集群管理，包括调度、负载均衡以及全局 TSO 时间戳生成等工作。PD 本身也是一个无单点故障的高可用集群。

TiDB 使用 TiFlash 列存储引擎来支持实时数据分析。它通过 Raft learner 实现异步复制，结合 MVCC 提供强一致性读取能力，同时支持计算下推，从而实现 AP/TP 场景彼此互不干扰。启用 TiFlash 后，TiDB 优化器会根据查询代价自动选择 TiKV 行存或 TiFlash 列存，以获得更优查询性能。

基于这样的分布式架构设计，TiDB 集群能够实现整体高可用与数据强一致性。即使少量副本丢失，系统也可以自动完成数据修复和故障切换，而不会影响业务层正常运行。TiDB 还支持跨地域、跨中心的异地多活部署。

2，云上TiDB的实现和功能

近年来，京东智联云客户对数据库性能和数据处理能力的要求不断提升。针对这类需求，京东智联云联合 PingCAP，基于 TiDB 推出了云端分布式数据库——Cloud-TiDB，重点面向高性能、高可靠和高可用的企业级业务场景。

上图展示了京东智联云 Cloud-TiDB 的整体架构。依托这一架构，Cloud-TiDB 提供了多项业务价值较高的核心能力，包括水平弹性扩容、备份恢复、实时数据分析、数据迁移与同步，以及云端监控告警等功能。

**水平弹性扩容。**TiDB 支持在线动态增减存储节点和计算节点，具备接近无限的水平扩展能力。完成扩容或缩容后，数据库还能自动进行数据再均衡。
**备份和恢复。**TiDB 支持自动 / 手动全量备份，并将备份数据存储在 OSS 中。恢复时不会覆盖原有集群，可有效降低误操作风险。
**实时数据分析。**在支持 OLTP 事务处理的同时，提供业务数据的实时分析与实时处理能力。
**数据迁移和同步。**支持全量 / 增量迁移，并可将数据同步到 MySQL、Kafka 等下游存储系统。
**监控与告警。**TiDB 提供丰富的监控指标，支持通过浏览器直接访问。云监控可提供资源层和业务层的监控告警，云日志还能配置错误日志监控报警。除了上述能力之外，在实际落地中，Cloud-TiDB 的另一项显著优势是更低的运维成本。Cloud-TiDB 能够很好地满足云服务按需伸缩的要求，帮助用户更精准地控制资源使用，避免资源闲置与浪费。

选择一项新技术，本质上也是在选择一个生态体系。生态越成熟，开发效率和运维效率通常也越高。TiDB 生态的一大优势在于兼容 MySQL 协议，因此可以充分复用成熟的 MySQL 生态资源。包括 MySQL 的数据库驱动、第三方开发 / 管理工具，以及数据交换 / 数据迁移工具等，基本都可以直接用于 TiDB 数据库。

此外，TiDB 还可以与其他主流数据处理技术实现高效互联。例如，TiDB 中的数据能够方便地导入 Kafka，接入 Flink，乃至 Hive、HDFS、Amazon S3、Spark 等平台。用户无需担心技术锁定问题，这也进一步夯实了 TiDB 生态持续繁荣的基础。

在分享最后，葛老师也对云数据库的发展趋势进行了展望：

分布式正在成为未来技术演进的重要方向之一。从操作系统，到应用程序，再到数据库，整体都在朝着分布式架构持续演进。作为分布式数据库代表，TiDB 正好契合这一技术趋势。与此同时，数据库上云带来的优势也非常明显，例如弹性调度、更容易与 AI 能力深度结合，以及更贴近用户业务视角地实现智能化数据处理优化。

从长期来看，数据库上云能够在开发效率、运维效率和系统稳定性等多个层面带来显著收益。也正因此，京东智联云选择将 TiDB 云化，就是希望为用户带来更高效、更稳定、更灵活的使用体验。

二、TiDB在大数据量和高并发场景下的应用

葛老师分享结束后，来自 PingCAP 的 TiDB 生态技术布道专家戚铮，进一步介绍了 TiDB 在大数据量和高并发业务场景下的应用实践。

1，TiDB与SHARDING 在 OLTP场景下的解决方案对比

当企业面临海量数据需求时，通常也会伴随数据规模在短期内快速增长的压力。这类业务要求数据库具备快速扩容能力和高并发处理能力，并在响应延迟与吞吐量等关键指标上保持较高水平，以应对突发流量和高峰访问。而 OLTP 场景主要涉及线上 2C 交易，对数据库稳定性要求极高，任何性能波动都可能直接影响终端用户体验。

针对这类需求，业内常见解决方案主要可分为 Sharding、NewSQL 和中间型的 DB-Based 等几类。其中，ShardingSphere 和 TiDB 分别是第一类与第三类方案中的典型代表。两者都是当前非常活跃的开源项目，也分别代表了解决海量数据问题的两种主流思路。所谓 Sharding，即分库分表，实践中通常包括水平拆分和垂直拆分两个维度。垂直拆分一般按照业务模块或数据类型划分，水平拆分则常见于按取模、按时间、按冷热数据等方式拆分。作为分库分表思路的代表，Sharding Sphere 的架构大致如下：

与前文介绍的 TiDB 架构相比，Sharding 架构中的数据备份、高可用、监控告警等能力，通常还需要借助周边第三方工具进行组合与配置。而 TiDB 本身就是一套完整的分布式数据库解决方案，能够一站式满足用户对高性能数据库的多方面需求。如今，ShardingSphere 也在新版本中逐步向完整分布式数据库方案演进，这从侧面说明了分布式数据库正在成为未来发展的必然趋势。

2，TiDB的海量数据应用案例

TiDB 的设计初衷，就是为了解决分库分表所带来的诸多问题。不过，也并非所有场景都适合立即迁移到 TiDB。具体来说，如果业务不会快速增长、请求逻辑较为简单，且不存在分布式事务需求，那么这类场景未必适合优先迁移。除这类情况之外，大多数面向海量数据和高并发的业务需求，都可以通过迁移到 TiDB 获得更好的解决效果。戚老师在分享中列举了多个典型实践案例。

某社区个性化首页与推送业务。由于海量用户的个性化推荐与推送特性，数据库每天需要生成 30 亿条数据，历史数据规模更是达到万亿级别，业务对吞吐量和访问延迟也极为敏感。该客户原有 MySQL 方案采用分库分表架构，但 MySQL 实例数量已达到上百个，系统风险与延迟表现都难以继续满足业务需求。经过深入调研后，用户认为 TiDB 是唯一能够同时满足高扩展性、强一致性和高可用需求的数据库解决方案，因此最终决定全面迁移。在迁移过程中，PingCAP 通过 Lightning 快速导入工具结合 DM 工具实现平滑迁移，迁移完成后又进行了多轮优化，最终很好地满足了业务要求。尤其令用户满意的是，新架构具备极强的横向扩展能力，迁移后数据量从 1.3 万亿逐步增长到 1.8 万亿，系统性能与可用性依然保持在较高水平，整体成本相比原方案也没有明显上升。

某电信个人账单系统。该客户的账单总表规模达到 80 亿条数据，对数据库性能要求非常高，而原有的 MyCAT 方案已接近扩展上限，只能存储不足一年的历史数据。由于 MySQL 分库分表模式已经接近处理瓶颈，继续增加分片会引入更多问题，因此用户选择使用 TiDB 完成数据库升级。迁移到 TiDB 后，单表数据量可直接达到 100 亿级，数据保存周期也由半年提升至 3-5 年，同时 QPS 与延迟指标都得到显著优化。

戚老师还介绍了某 O2O 平台 PMC 订单流水业务、某金融核心账务系统，以及某互金营销平台迁移至 TiDB 的案例。这些案例的共同点在于，用户原有的分库分表数据库架构都遇到了增长瓶颈，并对业务稳定性和发展带来了越来越明显的负面影响；而在迁移到 TiDB 之后，原有瓶颈基本得到彻底解决，迁移过程中也没有发生严重故障，整体成本投入依然处于可控范围内。

3，TiDB 5.0 亮点解析

在分享的最后环节，戚老师介绍了 TiDB 5.0 版本在性能优化方面的亮点与细节，主要包括以下几项重要特性。

**Async Commit。**旧版本 TiDB 采用两阶段提交机制，事务开销相对较大。Async Commit 主要在第二阶段实现异步提交，对于小事务能够达到类似 1PC 的效果，从而带来一定的性能提升。

**Clustered Index。**新版这一特性非常适合条件范围包含主键列的查询，类似 InnoDB 聚簇索引，可以减少这类查询的回表成本。根据 TPCC 测试结果，新版在这方面能够带来一定幅度的性能提升。

**Compaction Filter。**这一特性主要用于优化后台自动整理和压缩数据时引发的性能抖动问题。开启后，QPS 波动的标准差可降低到 5% 以内。

**SATA SSD 优化。**结合 compaction filter、fsync control、compaction guard 等新增能力，TiDB 5.0 版本在 SATA SSD 场景下的吞吐量与延迟表现相比 4.0 版本有了明显改善，同时由于 SATA 磁盘自身抖动带来的 QPS 波动也显著下降。

三、突破容量极限，TiDB打破企业数据库性能瓶颈

与传统分库分表方案相比，TiDB 是真正意义上的一站式分布式数据库整体解决方案，能够更好地满足企业在业务高速增长、海量数据高并发、实时数据分析以及金融级高可用等场景下的严苛要求。通过本场直播中两位老师的精彩分享，读者不仅对 TiDB 数据库的核心能力、实现原理和落地实践有了更深入的了解，也更加清晰地认识到 TiDB 数据库服务在企业级应用中的突出优势。

正如两位老师所提到的，分布式数据库已经成为行业发展的必然趋势，而 TiDB 正是在这一趋势下快速成长的代表性产品，有望成为越来越多企业解决数据库性能瓶颈、应对海量数据挑战的重要选择。与此同时，TiDB 在京东智联云上的落地实践，也为企业更快采用 TiDB、尽早释放 TiDB 的业务价值与技术红利，提供了一条高效便捷的路径。

如果想了解更多京东智联云与 TiDB 相关内容，或获取本次演讲 PPT，可在评论区留言PPT，我们会及时回复获取方式。

点击_【阅读原文】_查看视频回放链接。