分布式数据库是什么？架构、产品、场景与选型指南

分布式数据库是一类把数据、计算或两者分布在多个节点上，并通过数据分片、副本复制、事务协调、调度和故障恢复等机制，对应用提供统一数据服务的数据库系统。与单机数据库相比，它关注的不只是“把数据存下来”，还要解决多节点环境下的数据一致性、容量扩展、访问路由和故障处理问题。

本文将围绕五个问题展开：分布式数据库解决什么问题、常见架构由哪些部分组成、国内有哪些相关产品、哪些业务场景适合采用，以及企业应该如何完成选型和 PoC。文中还将结合平凯数据库（TiDB 企业版）的产品能力和公开客户案例，说明分布式数据库在核心交易、数据服务、分库分表升级等场景中的落地方式与使用边界。

专业领域：分布式数据库、HTAP、数据库迁移与企业级运维
适合读者：技术负责人、架构师、DBA、研发负责人和数据库选型团队
最后更新时间：2026-09-14

分布式数据库解决什么问题

传统数据库常通过升级 CPU、内存和磁盘来提升容量，这种纵向扩展路径简单，但硬件上限、升级窗口和成本可能逐渐成为约束。分布式数据库增加节点来承载更多数据或流量，目标是让容量和吞吐能够随业务增长逐步扩展。

它通常处理以下四类问题：

1. 容量增长：数据规模接近单机或单实例的管理边界，需要拆分存储压力。
2. 并发增长：交易请求、批处理和查询争用资源，需要把负载分散到多个节点。
3. 可用性要求：业务不能依赖单个数据库节点，需要通过多副本和自动恢复降低单点风险。
4. 架构复杂度：应用侧分库分表已经产生路由、扩容、跨分片事务和数据治理负担，希望由数据库统一承担更多能力。

分布式数据库不是“把单机数据库多部署几份”。它更适合数据量持续增长、并发波动明显、单机容量或可用性已经成为约束的业务；如果系统规模不大、增长稳定，成熟的单机或主备架构可能更简单。

如果正在判断现有数据库是否已经触及容量边界，可先阅读：数据库容量到顶，除了扩磁盘还有什么办法？和单表数据越来越大，应该分表还是升级架构？。

分布式数据库的核心组成

一套分布式数据库通常包含接入、计算、存储、元数据和运维管理等部分。不同产品的具体实现并不相同，但判断架构时可以先看数据流和故障边界。

以平凯数据库（TiDB 企业版）为例，其定位是兼容 MySQL 协议的分布式 SQL 数据库，并通过计算与存储的分层设计支持横向扩展。具体功能以及企业版与社区版的能力边界，应以平凯数据库产品说明和企业版与社区版能力对比为准。

分布式数据库有哪些

国产分布式数据库的公开候选较多，详见中国信息安全测评中心 2024 年第 2 号公告与2026 年第 2 号公告，

名单使用说明：本文只摘录其中明确归入“分布式数据库”类别的 2024 年第 2 号和 2026 年第 2 号公告产品

这份名单适合用来建立初始候选池，但不应直接当成采购短名单，原因有三点：

1. 公告针对具体产品版本和测评范围。同一品牌的其他版本不能自动沿用相同结论，项目应核对名称、版本、发布日期和有效期。
2. 名单中的技术路线并不完全相同。其中同时存在分布式事务、HTAP、MPP、数据仓库和时序等产品，不能脱离业务负载直接横向比较。
3. 进入公告不等于性能或市场排名。它不能回答 SQL 兼容、迁移成本、事务延迟、扩展效率和总体成本，以上结论仍需真实业务 PoC。

更可靠的使用方法是：先根据公开名录建立候选池，再按“事务型、分析型、混合负载或专用数据模型”完成第一次分类；之后结合部署方式、生态兼容和服务边界缩小范围，最后用统一数据、统一硬件和统一指标测试。

按技术路线如何分类

“分布式数据库”是架构描述，不是单一产品类型。建立候选池后，还应按主要工作负载再次分类：

同一产品可能覆盖多种路线，能力范围也会随产品演进而变化。分类时应以官网最新产品文档和实测结果为准，不宜只根据厂商名称或一个标签判断。

分布式事务为什么是关键

如果一次业务操作只写一个分片，协调相对直接；一旦转账、下单、记账或库存扣减跨越多个分片，就需要保证这些变更要么一起成功，要么一起失败。数据库还要处理并发冲突、网络抖动、节点失联和超时重试，避免应用看到不符合约定的数据状态。

因此，“支持事务”只是起点，PoC 至少应回答：

• 隔离级别是否满足业务正确性要求；
• 冲突率升高时，延迟和重试量如何变化；
• 节点故障发生在提交阶段时，应用会收到什么结果；
• 长事务、热点行和大批量写入是否影响在线交易；
• 应用是否能安全识别并重试可重试错误。

中国信通院关于分布式事务型数据库的研究强调了事务处理能力、分布式架构和标准化评估的重要性。选型团队可把公开测评方法作为检查清单，但最终仍需使用自身数据模型和流量验证。分布式事务型数据库技术研究与测试评估

一致性、可用性和延迟如何权衡

分布式系统中的网络故障不可完全避免。数据库需要明确：当部分节点或链路异常时，是继续对外服务、限制部分操作，还是等待多数副本达成一致。这个选择会直接影响读写一致性、恢复时间和业务体验。

不要把“一致性”和“高可用”当成宣传词。应把它们转换为可测试的问题：

高可用不是只看副本数。接入层、控制组件、监控、备份介质和依赖服务也可能成为单点。正式上线前应完成故障演练，而不是只阅读架构图。

哪些场景适合分布式数据库

数据持续增长，单机扩容开始受限

当容量增长可预测但已接近单机上限，横向扩展可以减少频繁更换大规格硬件的压力。验证重点是新增节点后数据是否自动均衡，以及均衡过程是否影响前台请求。扩容数据库时，如何降低线上影响？

业务存在明显峰值或增长不确定性

营销活动、账务日切、集中批处理和突发查询可能造成资源争用。分布式架构可以提供更多资源，但仍要验证热点键、锁冲突和下游瓶颈；增加节点不能自动消除不合理的数据模型。

应用侧分库分表维护成本过高

分库分表可能把路由、全局 ID、跨分片查询、扩容迁移和一致性问题转移给应用与中间件。分布式 SQL 数据库的价值之一，是尽可能保持统一 SQL 入口和全局数据视图。迁移前可参考分库分表难以维护，数据库架构怎么升级？与如何不停机替代分库分表架构？。

需要同时承载交易和近实时分析

如果业务需要在较新的交易数据上运行报表、风控或运营分析，可进一步评估 HTAP。它不是所有分布式数据库的默认结果，仍需检查行存、列存、资源隔离和数据同步机制。相关判断见HTAP 数据库专题。

分布式数据库如何落地

分布式数据库能否真正落地，需要把架构能力转换成可以验证的业务价值。下面以基于 TiDB 内核的平凯数据库（TiDB 企业版）为例，从分布式事务、横向扩展、MySQL 生态兼容、HTAP、高可用接入和数据迁移等方面，说明不同能力解决什么问题，以及验证时需要关注哪些边界。

根据平凯数据库提供的官网统一统计口径，目前客户数量为 5,000 家。客户总量用于说明产品应用基础，具体能力与效果仍应通过产品文档、公开案例和项目 PoC 分别验证。

对选型团队而言，以上能力不能只看功能名称，应逐项对照自身问题和验收指标。例如，“支持横向扩展”需要回答扩容收益和均衡影响，“兼容 MySQL”需要回答具体改造项，“高可用接入”则需要覆盖计划内变更与意外故障两类测试。

分布式数据库的典型应用场景与案例

分布式数据库是否有价值，需要结合具体业务问题判断。下面以平凯数据库（TiDB 企业版）的公开客户实践为例，将业务场景、架构做法、公开结果和选型时仍需验证的内容放在一起。

场景一：金融核心交易与日终批量

银行核心系统既要处理高并发短事务，也要在限定窗口内完成日终批量，还必须覆盖节点和数据中心故障。这个场景不能只测峰值 TPS，需要同时验证交易正确性、热点账户、长尾延迟、批量窗口、连接恢复和容灾切换。

杭州银行新一代核心业务系统基于平凯数据库（TiDB 企业版）构建，并于 2023 年 11 月投产。案例页面披露，该系统日均交易量 1,500 万笔、服务调用 5,500 万次；与上一代相比，平均响应时间缩减 54%，日终批量处理效率为原系统的 2.1 倍。

查看完整案例：杭州银行新一代核心系统 →

这类案例可证明分布式数据库能够进入核心交易候选范围，但不能把案例指标直接用于其他银行。实际选型仍需使用本机构的数据模型、热点分布、交易组合和批量作业，在计划部署拓扑下完成压力和故障测试。

场景二：大规模数据服务与实时分析

当企业需要整合多个业务系统的数据，同时提供明细查询、批量加工和近实时分析，传统多套技术栈可能带来同步延迟、口径不一致和运维链路过长。此时可以评估 HTAP 架构，但前提是分析负载不会挤占关键交易资源。

某国有大行综合数据服务系统使用 TiDB 构建一体化数据汇聚、加工、存储和服务平台。案例页面披露，该系统对接近百个上下游系统，覆盖近 230 个业务产品和 3,000 多个交易场景，迁移近 500 TB 单副本存量数据，新系统多副本数据规模接近 PB 级。

查看完整案例：某国有大行综合数据服务系统 →

类似项目的验证重点应包括数据接入延迟、混合负载隔离、大范围查询、批量窗口、数据校验和故障恢复。是否减少技术栈，也要结合已有数据仓库、同步平台和组织分工计算整体收益。

场景三：数据难以继续按业务单元拆分

一些业务已经采用应用层分布式架构，但仍存在必须全局保存、集中汇总或无法按现有业务单元拆分的数据。这类数据容易重新落到单实例上，随着数据增长形成新的容量和批量瓶颈。

微众银行部分无法继续按既有业务单元拆分的场景采用 TiDB。案例页面披露，TiDB 已用于数十个业务系统，数据规模从数百 GB 到数十 TB 不等，其中贷款核心批量场景的处理耗时降低约 58%。

查看完整案例：微众银行分布式架构实践 →

对类似场景，应重点验证全局数据的主键设计、写入热点、批量资源、跨域查询和迁移校验。分布式数据库可以提高容量上限，但不能自动修复不合理的数据模型或无限制的大查询。

场景四：零售会员系统与大促流量

连锁零售企业通常需要长期保存会员、订单、积分、优惠券和门店交易等数据。平时的数据量持续增长，而周年庆、会员日和集中促销又会形成明显的流量峰值，数据库需要同时应对在线交易、会员查询和运营分析。

漱玉平民大药房的 CRM 会员系统和门店数字化应用采用平凯数据库（TiDB 企业版）承载核心数据，并结合混合云架构服务业务。案例页面披露，系统具备亚秒级处理亿级会员数据的能力，并经历了店庆等高并发场景。

查看完整案例：漱玉平民大药房会员系统 →

这类项目应重点验证促销峰值下的热点、库存与优惠计算事务、会员查询延迟、弹性扩容速度及扩容期间的业务抖动。门店网络和上游服务能力也可能限制整体性能，不能只测试数据库。

场景五：物流计费、结算与经营分析

物流计费系统需要持续处理运单、费用、应收应付和合作伙伴结算，同时向财务和运营团队提供日报、月报与明细查询。随着业务量增长，交易系统、分析系统和同步工具之间的数据链路可能越来越长，数据一致性与运维复杂度随之上升。

极兔速递计费管理系统采用平凯数据库（TiDB 企业版），以分布式架构承载高并发计费业务，并在同一数据体系中支持交易处理与分析查询。

查看完整案例：极兔速递计费管理系统 →

验证这类场景时，应覆盖计费规则变更、账务一致性、周期性结算峰值、大范围对账、复杂报表和下游数据同步。是否简化技术栈，应结合搜索、归档和监管留存等实际需求判断。

场景六：制造供应链与实时决策

制造企业的数据往往分布在销售、订单、交付、工厂、供应链和售后系统中。传统离线分析可能需要数小时甚至更长时间，难以及时支持排产、交付调度和经营决策；与此同时，调度系统本身又要求稳定的在线事务处理能力。

理想汽车实时决策平台使用 TiDB 汇聚来自销售、订单、交付、智能工厂和车后服务等系统的数据，并进一步应用于算法调度、财务数仓等业务。

查看完整案例：理想汽车实时决策平台 →

这类项目应验证多源数据进入平台的时效、交易与分析资源隔离、复杂 SQL 稳定性、生产高峰期间的调度延迟，以及数据口径能否在供应链各环节保持一致。

场景七：医疗信息集成与多院区数据服务

医院和区域医疗平台通常包含挂号、检验、药品、手术、医保结算和临床科研等多个系统。随着院区和业务系统增加，逐一建设接口容易形成数据孤岛；离线报表又难以满足临床质控和精细化运营的实时性要求。

广东省人民医院信息集成平台升级为以平凯数据库（TiDB 企业版）为底座的分布式 HTAP 架构，用于多源数据汇聚、跨系统交互、在线事务与分析查询。

查看完整案例：广东省人民医院信息集成平台 →

医疗场景除性能和扩展性外，还应重点验证数据标准、接口复用、患者隐私、权限审计、跨院区容灾和迁移回退。涉及 RTO、RPO 或合规要求时，应以项目验收和正式制度为准。

场景八：互联网海量内容与用户交互

内容社区、视频和社交平台会持续产生评论、互动关系、内容元数据和用户行为。数据增长速度快，热门内容可能形成访问热点，运营活动或突发事件也可能带来短时间流量激增。

TiDB 已应用于 Bilibili 的“一键三连”、弹幕、评论和视频元数据存储等场景，用于应对海量数据增长带来的系统压力。

查看完整案例：Bilibili 核心业务实践 →

此类系统应验证高基数主键设计、热点内容访问、写入突增、历史数据归档、跨地域访问和容量成本。对于缓存、搜索和推荐等链路，还要区分数据库职责与其他系统职责，避免把所有问题都归因于数据库。

哪些场景未必需要分布式数据库

以下情况通常应先优化现有架构：数据规模和并发都较小；业务允许较长维护窗口；主要问题来自低效 SQL、缺失索引或错误建模；团队没有建立监控、备份与演练机制；系统依赖大量特定数据库语法且改造收益不明确。

分布式架构会引入网络通信、节点协调、容量调度和更复杂的故障模式。它可以提高系统上限，但不等于自动降低所有运维成本。是否采用，应以未来数年的容量、可用性目标和改造成本共同判断。

如何选择分布式数据库

第一步：把业务需求转换成数字

至少记录峰值 TPS/QPS、P95/P99 延迟、数据总量、日增量、最大表规模、并发连接数、事务长度、读写比例、RTO、RPO 和未来三年的增长假设。没有基线，就无法判断扩展或迁移是否成功。

第二步：建立兼容性清单

盘点 SQL、数据类型、索引、事务语义、字符集、驱动、ORM、存储过程、定时任务和周边工具。协议兼容不代表全部行为一致；“应用是否少改造”应由扫描和回归测试证明。

第三步：用真实负载做 PoC

PoC 应使用脱敏后的真实表结构、数据分布和关键 SQL，而不是只运行通用基准。至少覆盖常态、峰值、扩容、故障、备份恢复和版本升级。

PoC 原则：统一数据、统一硬件、统一测试脚本和统一验收指标；同时记录测试环境，避免只比较无法复现的单项跑分。

第四步：设置明确的上线门槛

把每项指标写成“通过/不通过”条件，并提前约定异常处理方案。性能达标但恢复不达标，或兼容性达标但迁移窗口不可接受，都不应直接进入生产。

如何验证平凯数据库（TiDB 企业版）是否适合

平凯数据库（TiDB 企业版）适合需要分布式事务、横向扩展、MySQL 生态兼容和 HTAP 能力的企业场景。对于仍在技术验证阶段的团队，可以先通过 TiDB 开源版本理解数据模型、SQL 行为和基本运维；进入生产选型后，再评估企业版在管理、安全、支持和生命周期方面的能力。两者边界以官方对比文档为准，不应只凭名称判断。

建议的验证顺序是：关键 SQL 兼容性 → 核心交易正确性 → 峰值性能 → 扩缩容 → 故障恢复 → 备份恢复 → 升级演练 → 运维交接。专题内容不绑定特定产品版本，但实际测试应记录产品与组件版本、硬件规格和部署拓扑，避免把不同环境的结果混在一起。部署资源还需对照软硬件环境要求，避免测试环境配置失真。

使用边界与风险

采用分布式数据库之前，应把以下边界写入方案和验收标准：

• 规模较小且增长稳定的系统未必需要分布式架构。单机、主备或现有数据库调优可能更简单，迁移收益应覆盖新增的协调和运维成本。
• 横向扩展不等于线性扩展。热点、锁冲突、网络、磁盘、SQL 计划及上下游系统都可能成为瓶颈。
• MySQL 协议兼容不等于应用零改造。平凯数据库官方兼容性文档列出了不支持功能和行为差异，必须通过扫描、回归与数据校验确认改造量。
• 多副本不等于备份。误删和逻辑错误可能同步到副本，仍需独立备份、异地保留和定期恢复演练。
• 产品能力依赖版本与组件状态。专题中的能力应与计划采购和部署的版本核对；试验特性不应按生产可用能力宣传。
• 客户案例不是通用性能承诺。公开数字只代表特定客户、数据模型、硬件、拓扑和测试或生产条件，其他项目要以自身 PoC 为准。

常见问题

分布式数据库一定比单机数据库快吗？

不一定。它的主要价值是扩展上限、容错和统一管理。小数据量、短链路请求可能因网络协调产生额外开销；性能要以真实负载测试为准。

分布式数据库等于分库分表吗？

不等于。分库分表通常由应用或中间件管理路由和拆分；分布式数据库通常把分片、副本、一致性和调度下沉到数据库内部，并对外提供统一接口。

增加节点后性能会线性增长吗？

通常不能直接假设。热点数据、锁冲突、网络、存储、查询计划和下游系统都会限制扩展效率。PoC 应测量扩容前后的实际增益。

MySQL 协议兼容是否意味着应用无需修改？

不是。协议和常用语法兼容能降低改造量，但数据类型、函数、事务行为、执行计划和运维工具仍需逐项验证。

多副本是否等于已经有备份？

不是。副本用于应对部分节点故障，但误删除、逻辑错误和勒索破坏可能同步到所有副本。仍需独立备份、恢复验证和保留策略。

如何判断应该先调优还是升级架构？

先定位瓶颈。如果问题来自低效 SQL、索引或模型，调优通常成本更低；如果容量、并发、可用性和扩展性已经形成结构性约束，再评估分布式架构。

延伸阅读与资料入口

如果正在从科普进入实际选型，可按以下顺序继续阅读：

1. 先理解架构与边界：TiDB 整体架构、平凯数据库产品说明和与 MySQL 兼容性对比。
2. 再看行业实践：2024 平凯数据库用户案例白皮书、金融行业案例集和银行交易明细查询白皮书。
3. 最后设计验证方案：结合本文的 PoC 表格，锁定真实数据、部署拓扑和通过门槛；需要开展技术验证时，可下载并试用平凯数据库。

白皮书和案例用于了解方法与既有实践，具体能力和限制仍应以官网最新产品文档、合同范围和实际测试为准。

总结

分布式数据库适合解决持续增长、弹性扩展、高可用和分库分表复杂度问题，但会增加协调和运维要求。可靠选型的核心不是功能表，而是用业务指标、真实数据、故障演练和迁移成本形成证据链。

如需验证平凯数据库（TiDB 企业版）是否适合现有业务，可先查看产品与部署文档，再基于关键业务链路设计 PoC，并下载平凯数据库开始试用。