企业官网建设流程全解析

先问一个问题：如果你正在搭建一个业务系统，数据库选型的时候，技术负责人跟你提了一嘴“要不直接上分布式数据库吧”，你心里是什么感觉？很多人第一反应是“听起来很牛”，但紧接着就是一连串的问号——它到底是啥？跟 MySQL 的主从集群有什么区别？是不是上了之后就一劳永逸了？这些问题如果没想清楚就贸然立项，踩坑的概率会非常高。

我接触分布式数据库差不多也有七八年了，从早期的中间件分库分表方案，到后来的原生分布式数据库，再到云厂商提供的各种 Serverless 形态数据库，多多少少都折腾过。今天想用一篇比较长的文章，把这个概念彻底讲透。我不会堆砌教科书上的定义，而是从“这东西到底解决了什么问题”出发，把它的架构逻辑、核心难点、选型思路和落地避坑经验都过一遍。不管你是刚入门的技术新人，还是正在做数据库选型的负责人，这篇文章应该能帮你把分布式数据库的轮廓看清楚。

1. 从“单机扛不住”说起：分布式数据库到底解决什么问题

想理解分布式数据库，得先理解它要取代的东西——集中式数据库，也就是传统那种跑在一台物理服务器上的数据库。

1.1 集中式数据库的瓶颈在哪

传统单机数据库，比如你熟悉的 MySQL、PostgreSQL，它们的设计前提是“一台机器搞定一切”。数据存在这台机器的磁盘上，计算用这台机器的 CPU 和内存，对外提供服务也靠这台机器的网络。在业务早期，这完全没问题，甚至一台普通的服务器就能扛住好几万的 QPS（每秒查询数）。但业务增长之后，麻烦就来了，而且通常是从三个方向同时来的。

第一个方向是存储容量。数据量从几十 GB 涨到几个 TB 甚至几十 TB，单块磁盘装不下了，虽然可以做 RAID 或者挂存储阵列，但成本会直线上升，而且单机文件系统本身的寻址能力也有上限。

第二个方向是计算能力。数据库要执行 SQL，尤其是复杂查询，非常吃 CPU 和内存。单机的 CPU 核数是有限的，内存插槽是有限的，到了瓶颈之后，你只能换一台更贵的机器。这个方向叫“垂直扩展”，垂直扩展的问题是：越往上走，价格越离谱，而且总有一个物理极限。

第三个方向是可用性。单台机器再稳定，也扛不住断电、硬件损坏、机房故障。一旦数据库所在的机器宕机，整个业务就挂了。传统方案是搞主从复制，备机接管，但备机方案在数据一致性、自动切换上需要大量运维投入，而且从节点往往只是“冷备”，业务高峰期也很难真正分担压力。

所以说，集中式架构的终极天花板，不是你不够努力，而是物理定律摆在那里。这时候就出现了另一条路——水平扩展：我不追求让一台机器变得无限强，而是让很多台普通的机器一起干活，对外仍然表现得像一台机器。这条路的产物，就是分布式数据库。

1.2 分布式数据库的三个核心特质

那到底什么叫分布式数据库？我用一句话概括：一个由多台独立计算节点组成的、通过网络协作完成数据存储和处理任务的系统，对用户来说，它看起来和一台传统数据库没有区别。

这句话里同时包含了三个核心特质：

第一，多节点协作。数据不再只存放在一台机器上，而是按照某种规则拆开，放到多个节点上。每个节点都是一个独立的数据库实例，有自己的 CPU、内存和磁盘。

第二，对应用透明。应用连接数据库的时候，只需要知道一个逻辑上的数据库地址，SQL 该怎么写还是怎么写，不需要关心这个表的数据到底分散在哪些物理节点上。这种透明性，是分布式数据库和“应用自己做分库分表”的一个关键区别。你自己搞分库分表，SQL 都要改，中间件要路由，业务代码要处理多数据源的事务，累得很；用分布式数据库，从应用视角看，它就是“一台能无限扩展的数据库”。

第三，具备完整的数据库能力。不仅仅是读写数据，还包括事务、索引、约束、SQL 解析优化等完整功能。早期有一些分布式存储系统只有 KV 读写能力，那叫分布式存储，不叫分布式数据库。只有当你需要执行带 Join、子查询、事务的 SQL，并且系统能帮你搞定这一切的时候，它才配得上数据库这个名字。

这里顺便提一个很多初学者容易搞混的点：“分布式数据库”不等于“数据库集群”。传统的 MySQL 主从复制集群也算多节点，但数据通常只在主节点上读写，从节点只是备份和扩展读能力，写能力没有水平扩展。真正意义上的分布式数据库，是写数据也在多个节点上并发执行，所有节点都是对等的或近乎对等的，系统整体能力随节点数量增长而线性增长。

2. 分布式数据库的分类与架构选型思路

搞清楚了它是什么，接下来要面对的是更现实的问题：市面上的分布式数据库那么多，它们是一回事吗？坦白说，不是。如果你把不同类型混为一谈，跑去看性能对比，或者用错误的运维姿势部署，一定会出问题。

2.1 OLTP 和 OLAP 两个截然不同的方向

先记住两个术语：OLTP（联机事务处理）和 OLAP（联机分析处理）。

OLTP 场景就是传统的业务系统，比如订单系统、支付系统、用户中心。特点是高并发、小数据量读写、强事务要求、响应时间要求毫秒级。你每次下单、每次登录，背后都是一堆 OLTP 操作。

OLAP 场景是数据分析、报表、BI，特点是数据量巨大、查询复杂、批量扫描为主、事务要求相对低。典型操作是凌晨跑一批报表任务，一跑就是几十分钟。

两种场景对数据库架构的要求差异非常大。OLTP 要求的是“短平快”，OLAP 要求的是“大而全”。分布式数据库在这两个方向上演化了截然不同的技术路线：

• 分布式 OLTP 数据库主打的是水平扩展、强一致性、分布式事务，代表技术路线是 NewSQL；
• 分布式 OLAP 数据库主打的是列式存储、大规模并行处理（MPP）、计算与存储分离，代表技术路线是大数据仓库、数据湖分析引擎。

所以当你准备选型的时候，第一个问题应该是：你的业务是偏 OLTP 还是 OLAP？或者换个更直白的问法：你的核心诉求是支撑高并发交易，还是做大规模数据分析？这个问题没有想清楚，后面所有的对比都是空谈。

2.2 中间件方案与原生分布式方案的区别

在 OLTP 这个方向上，还有一个非常经典的分类：数据库中间件方案vs原生分布式数据库方案。

中间件方案的代表思路是：底层仍然跑着多个 MySQL 或 PostgreSQL 实例，上面加一层分布式中间件，由中间件负责把 SQL 路由到正确的分片上。你可以把中间件理解成一个“调度员”，它对上伪装成一台数据库，对下管理着后面的多台真实数据库。

典型的架构是这样：你创建一张订单表，中间件按照某个规则（比如订单号取模）把数据分成 16 片 / 32 片，每片落在不同的数据库节点上。查询的时候，中间件解析 SQL，找到对应的分片，再到那片数据所在的数据库实例上执行。

原生分布式数据库则不一样。它从底层存储引擎开始就是为分布式设计的，数据分片、复制、分布式事务这些能力是数据库本身自带的，不是外面套的一层壳。

两者差异在什么地方？我举一个运维和事务上的例子。中间件方案里的分片数据库，本质上还是单机数据库，读写事务如果涉及多个分片，需要中间件协调分布式事务，性能损失比较明显；原生分布式数据库的引擎在设计之初就把多节点一致性当核心功能来优化，分布式事务的代价更低，能力边界也更清晰。

不过话说回来，中间件方案也有它的价值。很多团队已经在用 MySQL，积累了大量的 DBA 经验、运维工具和业务代码，一下子迁移到原生分布式数据库，可能面临 SQL 兼容性、运维体系重建的问题。中间件方案可以让你保留 MySQL 的底层能力，在上面平滑扩展。这是很多系统还在使用中间件方案的根本原因——不是它最先进，而是它最符合渐进式演进的现实需求。

2.3 选型时最关键的一个权衡：强一致还是最终一致

分布式系统和“一致性”这个词打交道最多。一致性指什么？通俗讲，就是一个数据被写进去之后，用户在什么时间点、从哪里读，能读到什么结果。

一致性有两种典型模型，一种是强一致性：写入成功后，所有后续读取都能立刻读到最新值，无论请求发到集群里的任何一个节点。第二种是最终一致性：写入成功后，系统不保证立刻读到最新值，但在一小段时间之后，所有节点会收敛到同样的状态。

这里有大名鼎鼎的 CAP 定理。它说得很简单：网络发生分区的时候，你必须在“可用性”和“一致性”之间二选一。你没法同时做到“所有节点都能响应请求”和“所有节点在同一时刻看到的数据完全一致”。

分布式数据库的架构选择，很大程度上就是对这个权衡的回答。

• 如果你选择了强一致性优先，那集群在出现节点故障或网络分区时，为了保证数据一致，可能会拒绝一部分读写请求，这会让业务出现短暂不可用，但数据是准的。
• 如果你选择了可用性优先，那故障时系统还能继续响应，但某些节点读到的可能是旧数据或未同步的最新数据，短暂的不一致对业务来说需能容忍。

很多业务系统对这笔账没算清楚就开始选型。记得我之前参与的一个模拟项目X，业务方提的需求是“绝对不能丢数据，同时全年 99.99% 可用”，但这两个要求在分布式系统里恰恰是冲突的。最后只能通过多副本强同步 + 智能路由把冲突区间压缩到极小，而不是真正消除冲突。选型之前把这份心思琢磨透了，比盲目追求某个技术指标有用得多。

2.4 常见分布式数据库架构速览

为了让你有个整体的画面，我把常见的几种分布式数据库架构按风格列一下：

Shared Nothing 架构：最经典、也是绝大多数分布式数据库采用的架构。每个节点拥有独立的 CPU、内存、磁盘，节点之间通过网络通信，数据按照分片规则分散在所有节点上。这种架构扩展性最好，加节点就能加容量和性能。它的代价是需要解决跨节点事务、分布式查询、数据分布均匀性这些复杂问题。

Shared Storage 架构：多个计算节点共享同一份底层存储（比如共享存储阵列或分布式文件系统）。计算节点可以灵活增减，存储可以独立扩容，这种架构比较适合计算和存储分离的场景。它的瓶颈通常在于共享存储的 IO 能力和网络带宽。

存储计算分离架构：存储层是一套分布式文件系统或对象存储，计算层由无状态节点组成，两者可以独立扩展。这种架构是云数据库的主流形态。好处是很弹性，存储成本低，扩缩容方便；挑战在于计算节点和存储节点之间的网络延迟必须控制好，否则查询性能会受损。

我们把话从头到尾捋一捋：没有哪一种架构是绝对完美的，关键在于你当前的业务规模和未来的演进路线，哪条路最吻合。下面要聊的是分布式数据库里面最核心的机制，也就是数据到底怎么放、怎么写、怎么保证一致。

3. 核心机制不踩坑：分片、复制与一致性如何配合

分布式数据库的技术复杂度，几乎全部集中在这三个词上：分片、复制、一致性。它们不是三个独立的技术点，而是一个互相咬合的齿轮组，缺一不可。我们一个个拆开讲。

3.1 数据分片：把数据拆开存放的艺术

数据分片（Sharding），就是把一张逻辑表的数据，按照某种规则物理地分散到多个节点上去。分片做得好不好，直接影响整个集群的性能表现。我见过不少团队自研分库分表，最后分布式系统做成了一堆热点，就是因为分片规则没选好。

常见的分片方式有三种。

范围分片：按照某个字段的值区间来分。比如订单表按订单 ID 分为四片：1-10000，10001-20000，20001-30000，30001-40000。范围分片的好处是区间扫描很快，对范围查询友好；坏处是可能产生热点，比如某段时间的订单量特别大，那这段时间的订单全部写进同一个区间对应的分片，其他分片闲置。典型场景就是时序数据，比如交易流水，大多数写操作都集中在“当前时间”这个区间，范围分片会导致最后的区间的节点压力巨大。

哈希分片：对分片键做哈希计算，然后对节点数取模。比如某张表的 id，计算 hash(id) % 4，得到 0/1/2/3，对应四个分片。哈希分片最大的好处是数据分布均匀，写压力能比较均匀地散到各个节点；坏处是区间扫描基本废了，相邻的数据很大概率落在不同的分片上，范围查询需要把多个分片扫描一遍再在中间层汇聚。

列表分片：按照枚举值来分，比如按地区把华东、华北、华南的数据各自放在一个分片上。列表分片适合数据天然有明确归属的场景，比如多租户应用，每个租户的数据分到独立分片。它的主要问题是各分片的数据量可能严重不均衡，大租户的数据量和小租户完全不是一个量级。

分片键怎么选？这是分布式数据库设计里最需要拍板的事。基本原则只有一个：选业务查询最常用的过滤字段，并且该字段的取值分布尽量均匀。

我举个真实的例子。曾经参与一个订单系统的分片设计，最初方案是按用户 ID 分片，觉得用户维度天然分布均匀。结果业务方说，运营活动经常要按“店铺维度”统计某时间段内的所有订单。如果按用户 ID 分片，一个店铺的订单会分散到几十个分片上，每次统计都要跨几十个分片聚合，慢得离谱。后来改成按“店铺 ID + 订单时间”组合设计分片规则，订单写入和店铺维度查询都舒服了很多。

分片键一旦确定，后续很难修改。想改分片键，基本等于做一次全量数据重分布，代价极大。这个投入在项目初期就要想清楚。

3.2 数据复制：副本是分布式系统的保命底牌

分片解决的是“数据放哪里”的问题，复制解决的是“数据丢了怎么办”的问题。

如果没有复制，每个分片只有一份数据，那么任何一个节点的磁盘故障，都会导致这部分数据永久丢失。这对数据库系统是不可接受的。所以分布式数据库会给每个分片的数据保留多个副本，通常至少三个。

副本有两种最常见的角色定位。

主从复制：分片有一个主副本（Leader）和若干个从副本（Follower）。所有写操作先到主副本上执行，然后主副本把写日志异步或同步地发给从副本，从副本按日志顺序重放，把数据更新到自己的存储中。读操作一般可以灵活选择主副本或从副本。主副本负责推进写进度，从副本负责提供冗余读能力。

多主复制：多个副本都接受写操作，然后把写操作互相同步。这种方式扩展性更好，但冲突处理的复杂度暴增。两个节点同时对同一行数据做了不同修改怎么办？分布式数据库通常需要引入版本向量、冲突合并等机制来协调。出于稳妥考虑，绝大多数分布式数据库在生产环境中依然采用主从模型——写收敛到主节点，读可以从节点灵活路由，这个模型最成熟也最容易压测预估性能。

副本同步还有一个细节非常关键：同步复制还是异步复制。

同步复制要求写操作在所有副本都确认成功之后，才能返回给客户端成功。这样的好处是一致性最强，坏处是任何副本的响应延迟都会拖累整个写操作。异步复制则允许主节点写成功就返回，后台再异步同步到副本，性能好但存在丢数据的风险窗口。很多数据库的“多副本强一致”实际上是“多数派同步”，也就是多数派副本确认成功就算成功，少数派副本落后没关系，这个机制引申出来的就是共识算法。

3.3 一致性层：共识算法和分布式事务

分布式数据库里面最硬核的部分，在于如何让所有节点对数据的“顺序”达成一致。节点收到写操作，到底谁先谁后？数据写入到了哪个版本？各个节点的日志如何保证一致？这些问题单靠拍脑袋解决不了。

Raft 协议和 Paxos 协议就是干这个的。它们是共识算法，解决的核心问题是：在一个由多个节点组成的网络中，即使某些节点宕机或者网络异常，剩下的节点依然能就某个决定达成一致。

用一个生活类比来理解：一个团队要决定中午吃什么，如果每个人只说自己的想法，最后一定乱套。共识算法就像是设计了一套表决机制：队长先发表提议，大家投票，超过半数同意则决定生效，哪怕有几个成员临时没在线，也不影响表决的推进。数据库里的写操作也是一样，一个节点提议“把某行数据改成 X”，整个分片的多数派节点都确认这个提议之后，这个修改才正式生效。这个“多数派”机制强大在哪？只要集群中还活着超过半数的节点，系统就能继续对外服务，不需要所有节点都在线。

分布式事务是另一个难啃的骨头。传统单库事务有个 ACID 特性，原子性、一致性、隔离性、持久性。在分布式环境里，一个事务可能涉及多个分片上的数据变更。比如一个转账事务，要同时更新账户表和流水表，这两张表可能在不同的分片上。单机时候的 lock 和 undo/redo 机制在分布式环境里不直接适用了，你需要一种协议来确保所有分片要么都提交，要么都回滚。

传统方案是两阶段提交（2PC）。第一阶段，协调者问所有参与节点“准备好了吗”，每个节点锁住自己的资源并回复；第二阶段，如果所有节点都回复准备好了，协调者发“提交”命令，所有节点执行提交。这个方式思路简单，但有两个问题：一是协调者本身如果挂了，整个事务卡死；二是持有锁的时间很长，性能损耗大。所以很多新式分布式数据库都在尝试优化事务协议，或者通过全局时钟、时间戳排序等思路来等价地实现事务效果，减少锁竞争和协调成本。

强调一下，这不是要你去实现共识算法，而是要你在理解分布式数据库行为和排障的时候，知道它背后有这么一套复杂的机制。当你看到集群发生网络分区时，有一部分节点进入只读模式，甚至服务短暂降级，这很可能就是共识机制在起作用，是它为了保证一致性做出的保护性反应。

3.4 CAP 定理的另一种理解方式

前面提到过 CAP，这里再延伸讲透一点。CAP 定理里的三个词：一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。

很多人把这个定理背下来之后，最喜欢问一个问题：“那我选 CP 还是 AP 啊？”

实际上，分区容忍性是必须选的。分布式环境没有“不分区的”前提，网络故障不是“可能发生”而是“迟早发生”。所以问题就简化成了：当分区发生时，系统优先保证一致性还是可用性？

• 选择 CP：任何节点之间通信断裂时，宁可停止服务也不返回错误数据。
• 选择 AP：任何请求来了都尽量处理，哪怕两个节点暂时各自为政，产生了不一致的数据，等网络恢复之后再慢慢对账。

数据库行业里有一个常见争议：到底有没有既能做到强一致又不损失可用性的数据库？理论上是没有的，CAP 定理说得明明白白。但工程上可以通过“把发生分区的影响范围做小”来逼近这个目标。比如把整个集群切成很多小的分片，每个分片独立完成多数派决策，一个分片发生故障只影响这个分片的数据，其余分片照常工作。这也是为什么优秀的分布式数据库能够做到，在节点故障时，只影响一小部分流量，而不是整个集群瘫痪。理解这个层级，比你背 CAP 定理的三句话有用得多。

4. 真正落地时怎么选：场景、成本与运维综合考量

技术机制讲完，回到最实际的问题：我到底要不要上分布式数据库？上了之后，运维上要注意什么？没有十足的把握，建议不要为了“技术先进感”而引入分布式数据库。这个系统复杂度和运维成本是看得见摸得着的。

4.1 什么时候该上、什么时候不该上

根据我的经验，有几个信号比较明确地说明“可以开始考虑分布式数据库了”。

第一个信号是数据量增长带来的相对性性能瓶颈。比如单表数据量达到亿级别之后，即使建了索引，写性能和查询延迟也开始波动，或者虽然勉强能用，但每次大查询都在消耗巨量 IO。第二个信号是业务高速增长，且对未来的容量预估是一个指数曲线。比如一个社交类应用，用户数从十万到千万是常态，运维团队不希望每半年做一次分库分表重构。第三个信号是需要跨地域多活。业务需要多机房部署，用户分布在不同的地域，希望就近读写，同时保持数据的一致性。

反过来，以下几个场景其实没什么必要上分布式数据库：

• 业务数据量在千万级别以内，单机 MySQL/PostgreSQL 性能绰绰有余；
• 团队没有专职 DBA 或对分布式基础设施熟悉度不够；
• 业务模型极其复杂，大量复杂的多表联表查询，这类 SQL 在分布式数据库下往往最痛苦；
• 数据一致性要求极高且运维力量薄弱，还不如老老实实用单机 + 主从。

这个判断逻辑很重要。我见过太多项目，业务量走到中等规模时，被某些厂商或者技术主管一顿“上分布式”的推荐，结果分布式数据库的优势没发挥出来，反而因为分布式事务和跨节点查询把原本简单的需求搞复杂了，团队维护成本直线上升。

4.2 迁移到分布式数据库时容易踩的坑

如果真的决定要上，重点说说迁移中高频出现的几个坑。

第一个坑是SQL 兼容性。特别是从标准 SQL 或某传统数据库迁移过来的时候，不是所有分布式数据库都完整支持各种 SQL 语法。某些很普通的 SQL 写法，比如“无分片键条件的 UPDATE”“跨节点的子查询嵌套”“Order by 一个非分片键的字段”，可能会触发全分片扫描或直接报错。解决方案不是天天看 SQL 文档，而是在迁移之前做一轮所有核心 SQL 的兼容性检查，把不兼容的 SQL 提前改造好。

第二个坑是分布式事务的代价被低估。在很多分布式数据库中，跨节点分布式事务虽然能做，但性能远不如单节点事务。有的数据库允许你把相关数据放在同一个分片里，从而在大多数场景下退化为单分片事务，这个技术术语叫“亲和性”，是分布式数据库的重要调优手段。如果业务在设计数据模型的时候，从一开始就把需要强事务的数据放在同一分片，性能会好很多。

第三个坑是数据分布不均导致的热点问题。即使使用了哈希分片，如果某个用户、某个商品、某个店铺的数据多到足以单独压垮一个分片，那就会出现典型的“热点分片”。比如电商平台的头部卖家，一个店铺的订单量是其他店铺的成百上千倍，即使按店铺 ID 分片，这个店铺所在的节点也可能被打爆。这种情况需要更细的分片策略——比如把大卖家单独分片，或者按订单 ID 直接分片，同时接受按店铺查询走跨分片聚合的代价。

这些坑都不是上来踩了就能立刻解决的，很多时候需要修改应用代码、调整数据模型，甚至反推业务设计。这也是为什么我总说：上分布式数据库不是一次数据库切换，而是一次架构升级。

4.3 运维实操中的常见问题与排查思路

分布式数据库的运维复杂度比单机数据库高一个数量级。下面列几项我在实际运维中总结出来的高频问题排查经验。

节点故障恢复后，性能突然下滑——大概率不是节点本身的问题，而是数据重新同步导致的。当节点从故障中恢复回来，它落后的数据会从其他副本拉取，这会占用大量带宽和磁盘 IO，间接影响业务流量。排查思路是检查节点间的网络流量和数据同步状态，必要时限制同步速度，让它在非高峰期完成数据补齐。

请求延迟梯度升高，且捉摸不定——原因很可能是跨分片路由发生了问题，比如某个查询需要用到的分片恰好没有命中的路由缓存，要现场去远端节点拉数据。排查思路是打开数据库的分布式执行计划，观察查询是否触发了不必要的跨节点数据传输。Solr 式的经验在这里管用：看到执行计划里出现 Exchange（数据重分配）算子，就要注意它的数量级。

主键由数据库自增生成时，出现性能急跌——传统数据库自增主键，在分布式数据库里如果全局唯一只能靠集中式分配器，容易变成性能瓶颈。你在设计表结构时，如果业务上不要求主键有序，可以改成使用雪花算法或 UUID 这类分布式生成的主键。这点很多新手不看设计手册，往往会踩。

写入延迟高，但 CPU/内存指标都正常——问题大概率出在副本同步策略上。如果配置的是同步复制，任何一个副本的慢 IO 都会拖慢主节点的写操作，而慢 IO 往往在节点指标上是看不出来的，要看它的磁盘写延迟、Page Cache 刷盘频率。解决方向是排查慢副本或者评估是否可接受异步复制模式。

集群整体短暂不可用，但节点存活正常——这种行为大概率由共识算法的重新选主触发。当少数派副本发生分区，触发重新选主，这期间会有短暂的不可写窗口。需要在监控层面提前配置好“选主耗时/复制延迟”等告警指标。

4.4 一个更务实的决策框架：从上到下的选型思考

最后，聊点方法论层面的东西。面对分布式数据库的选型，我一般建议团队按照下面的框架来思考，而非一开始就对比各家产品的性能参数：

第一层，业务诉求。业务是更看重写扩展性、读扩展性，还是事务能力？这些诉求写在纸面上，然后排优先级。很可能你会得到一个“其实我们是读多写少，读量大但没到单机极限”的结论——这种情况根本不用分布式数据库，从库加负载均衡就够了。

第二层，数据模型约束。数据之间是不是存在天然的聚合边界？比如组织架构、商家维度、用户维度。如果存在，那是用分布式数据库的绝佳条件，因为你把聚合边界定义成分片键，可以把跨分片事务控制到最小。

第三层，一致性需求。将业务容忍的不一致窗口列出来。比如“登录时允许短暂延迟同步”和“转账交易不允许分文差错”完全是两种诉求，它们对应的数据库能力要求也完全不同。

第四层，成本约束。包括授权成本、硬件成本、迁移改造的人力成本、后续 DBA 学习成本。分布式数据库的运维团队要求比单机 MySQL 高一个档次，招人、培训、流程规范的隐性成本很多人都没算进去。

把这个框架跑一遍，你会发现自己可能根本不需要一个“性能最强”的数据库，只需要一个“能力模型匹配当前业务”的数据库。这比任何参数对比表都靠谱。

回头再看看最开始那个问题：什么是分布式数据库？我现在会更愿意这样总结：它是一个让数据存储和计算能力可以跟着业务规模一起水平扩张的系统，同时你要为它的复杂性和运维成本买单。它不是什么银弹，也不是传统数据库的简单替代品——它有自己的适用边界，也有明确的优势和代价。如果你正站在数据库选型的路口，希望这篇文章能帮你把那些“听起来很牛”的概念，变成“我能清楚判断场景和代价”的实际决策依据，少踩一些只有亲身踩过才知道的坑。