核心定义：分布式数据库（DDDB）是把数据分散存储在多台独立节点上，通过网络协同，对外提供统一数据库视图，分为同构分布式（如 TiDB、OceanBase）、异构联邦库；常分为 NewSQL（兼顾 ACID + 水平扩展）和传统分片 MySQL 这类简易分布式方案。
✅ 优点
1. 水平扩展能力强（最核心优势）
单机数据库受 CPU、内存、磁盘上限约束，分布式可以通过加节点线性提升存储容量、读写吞吐量。 适合数据量持续暴涨、高并发业务（订单、日志、IoT、金融核心），不用频繁做昂贵的硬件升级。
2. 高可用与容灾能力更好
数据按分片 / 副本多节点冗余存储。单节点、单机房故障时，副本可自动接管，配合故障自动检测、主从切换，业务可以不中断。 支持跨机房、跨地域部署，满足异地灾备、多活架构要求。
3. 就近访问，降低访问延迟
支持数据按地域分片，用户请求路由到就近节点，减少跨地域网络延迟，适合全国 / 全球业务。
4. 负载天然分散
读写压力打散到多个节点，避免单机热点；可以单独对读请求做副本分离，读能力横向扩容。
5. 兼容多种业务场景，NewSQL 兼顾事务
NewSQL 类分布式库（TiDB、OB）同时支持：
像传统数据库一样支持强 ACID 事务、标准 SQL
拥有 NoSQL 的海量存储、高吞吐能力 对比单体 MySQL：解决单库单表上限；对比 Mongo 等 NoSQL：支持复杂关联、事务。
6. 硬件成本可控
可以使用普通 x86 服务器堆叠，不必依赖高端小型机、高端存储，大规模场景下硬件成本更优。
❌ 缺点
1. 架构复杂，运维门槛高
不再是单实例，需要管理分片、副本、元数据、调度组件、负载均衡、GC、raft/paxos 共识组。 运维人员需要懂分布式协议、网络、分片策略、扩容缩容、数据重分布；故障排查链路更长，一个慢 SQL 可能跨多个节点。
2. 事务代价高，跨分片事务性能差
单分片事务性能很好；
跨分片分布式事务（2PC） 会引入网络开销、锁冲突、协调成本，延迟上升、吞吐下降；
很多分布式库不推荐高频跨分片 join、跨分片事务，业务需要适配分片键。
重点：分片键设计是分布式数据库第一个大坑，分片键选错直接产生大量跨分片查询，性能雪崩。
3. 网络成为关键瓶颈
节点之间大量通信：数据重分布、事务提交、日志同步、元数据同步、join 下推。 网络抖动、丢包、带宽打满，会直接放大故障，甚至引发雪崩；内网网络质量要求远高于单机库。
4. 功能有损耗，SQL 支持不是 100% 等价
很多分布式库对复杂 SQL 有限制：
全局大排序、全库聚合、不带分片键的 where 查询容易扫全部分片；
部分存储过程、触发器、自定义函数、复杂 DDL 支持弱；
某些隔离级别、锁机制和传统 MySQL/Oracle 行为不一致，迁移容易踩坑。
5. 扩容 / 缩容会产生数据重分布开销
新增节点时，需要在节点之间迁移分片数据，占用带宽、IO；如果业务流量高，容易造成业务抖动，需要控制迁移限速、选低峰操作。
6. 一致性、性能、可用性三角权衡（CAP）
分布式系统无法同时满足：强一致性、高可用、分区容错。
选择强一致：写入延迟更高，节点失联时可能阻塞；
选择高可用：可能短暂读到旧数据（最终一致性）； 业务需要理解一致性模型，不能完全沿用单机数据库思维。
7. 调试、监控、问题定位难度大
一条 SQL 拆成多个子任务在多个节点执行，explain 分析更复杂；慢查询、死锁、超时问题根因定位链路更长；需要一套完善的观测体系（链路追踪、分片监控、事务监控）。
8. 小业务场景下性价比低
数据量不大、并发不高（比如几十万、几百万数据），用分布式属于过度设计： 资源开销更大、运维人力投入高、延迟反而比单机库更高。
📊 快速对比总结表
🎯 什么时候选 / 不选分布式数据库
✅ 推荐用：
单表数据预计突破亿级，单机存不下
业务并发持续上涨，读写压力单机扛不住
要求异地多活、跨城灾备
业务需要事务能力，不想纯 NoSQL 放弃 SQL 和事务
❌ 不推荐用：
数据量小、QPS 低，简单业务
大量高频跨分片 join、无分片键查询
团队缺少分布式运维能力
补充：常见选型提醒
TiDB：MySQL 兼容好，适合 MySQL 分库分表迁移；
OceanBase：金融级强一致，高可用，资源隔离强；
PolarDB-X：阿里系，适合云上 MySQL 分布式改造；
简单分片（ShardingSphere-JDBC）：中间件分片不是完整分布式数据库，没有全局元数据、自动负载均衡、自治故障转移，和原生分布式库有本质区别。