第 2 篇：关系型、NoSQL、NewSQL 怎么选
数据库选型这件事，一旦开场白是“哪个数据库更先进”，后面基本就容易跑偏。因为数据库不是手机，不是谁新谁就一定更适合你。真正决定成败的，通常是约束，而不是功能表。
更准确地说，选型之前要先把四个问题答明白：
- 数据之间是什么关系。
- 业务能接受什么级别的一致性。
- 系统的主要访问路径是什么。
- 团队能不能长期维护这套东西。
这四件事不清楚，后面不管聊关系型、NoSQL 还是 NewSQL，本质上都只是在选喜欢的名词。
关系型数据库仍然是默认答案
先说结论。在绝大多数业务系统里，关系型数据库仍然应该是默认答案，不需要不好意思。
原因也不复杂：
- 数据关系表达能力强
- 事务模型成熟
- SQL 能力完整
- 索引、约束、查询优化器生态都很成熟
- 团队通常已经有经验
只要你的系统有下面这些特征，关系型数据库基本都是优先解：
- 订单、支付、账户、库存、结算这类强事务场景
- 数据之间有明确关联
- 需要唯一约束、外键语义或者复杂筛选
- 报表和分析查询不算极端复杂，但不能太弱
- 团队的主力是后端工程师，不想引入太多额外心智负担
很多团队过早“逃离”关系型数据库，不是因为关系型不合适，而是因为自己把它用坏了。比如：
- 表结构完全没有生命周期设计
- 索引乱建或者根本没建对
- 大字段和热点数据全堆在主表
- 把线上库直接当分析库扫
- 拆库拆表时没有稳定的路由设计
这些都是工程问题，不是数据库类型问题。
NoSQL 的价值在于明确放弃一部分能力
NoSQL 这个词很宽，它底下包括键值、文档、列族、时序等不同系统。但它们有一个共同点：为了某种能力更强，主动放弃一部分关系型数据库擅长的东西。
也就是说，NoSQL 不是“更高级的数据库”，而是“取舍不同的数据库”。
它通常适合这些场景：
- 键值访问非常明确，读写路径单一
- 数据结构变化频繁，不适合固定表结构
- 海量日志、行为数据、时序数据
- 对最终一致性可以接受
比如 Redis 适合极低延迟的热点访问，文档数据库适合结构半稳定但变化频繁的对象模型，时序数据库适合高吞吐写入和按时间窗口聚合，宽列表适合大规模稀疏数据模型。
但 NoSQL 最容易踩的坑也很典型：前期因为灵活，建模成本看起来很低；后期因为缺少约束，治理成本开始爆炸。常见症状包括：
- 字段含义越长越歪
- 同一个对象在不同文档里结构不一致
- 查询需求一变，就发现原来的模型根本不支持
- 二级索引能力有限，补起来很难
- 业务层自己做事务、关联、唯一性校验，代码复杂度暴涨
所以如果你决定上 NoSQL，前提不是“它更快”，而是“你非常清楚自己准备放弃什么”。
NewSQL 适合想同时要事务和横向扩展的团队
NewSQL 之所以让人心动，是因为它试图同时满足两种需求：保留关系模型和事务，同时把水平扩展能力做上去。
这类系统通常适合下面这些情况：
- 单机关系型数据库已经接近扩展上限
- 业务又无法轻易拆库拆表
- 团队对 SQL 和事务有较强依赖
- 可以接受更复杂的架构和更高的产品学习成本
但这里一定要冷静一点。NewSQL 不是按个按钮就能同时拿到“传统 SQL 体验”和“无限水平扩展”。它背后通常要付出这些代价：
- 分布式事务的额外延迟
- 更复杂的数据分区设计
- 热点行、热点分区会更敏感
- 跨分片 Join 和聚合成本更高
- 观测和排障门槛明显上升
很多团队以为 NewSQL 会自动解决单机数据库的所有问题，结果只是把问题从单机调优换成了分布式调优。难度其实更高。
一个更实用的选型框架
如果你不想被各种术语带节奏，可以用下面这套更实用的判断框架。
1. 你的核心写入是否要求强一致
如果答案是“必须”，那就优先看关系型数据库，或者具备成熟事务模型的 NewSQL。不要一上来选最终一致系统，再在业务层手搓补偿、对账、幂等和回滚逻辑。那往往比直接用事务数据库更痛苦。
2. 你的读取模式是否稳定
如果绝大多数读取都是按主键、按单一维度、按固定路径访问，那键值或文档模型会很自然。反过来，如果查询条件经常变化，筛选组合很多，甚至有临时分析需求，关系型数据库通常更稳。
3. 数据是否天然具有关联
如果数据天然强关联，比如订单、支付、库存、履约这类对象之间经常要一起校验和查询，那强行拆到多种数据库里，短期看像架构升级，长期多半会变成同步链路增多、口径不一致、排障困难。
4. 团队最擅长维护什么
一个被团队真正理解、能稳定运营五年的普通方案，通常优于一个理论上更强、但没人真吃透的高级方案。数据库不是论文题，它会跟着业务跑很多年。
不要把数据库选型当作组织能力的替代品
很多选型争论表面看是技术分歧，实际上是在暴露组织问题。比如下面这些话，基本都值得警惕：
- 没有数据生命周期管理，却指望换数据库解决大表问题
- 没有性能基线，却希望靠分布式架构消除慢查询
- 没有变更规范，却希望托管服务自动兜底
数据库能解决的是存储与访问问题，解决不了工程纪律缺失的问题。
小结
选型没有银弹，但有一个很稳的原则：从最保守、最熟悉、最能表达业务约束的方案开始，只有当它真的成为瓶颈时，再去引入更复杂的数据库类型。
关系型数据库依然是大部分业务的默认答案。NoSQL 适合明确访问模型和明确取舍的场景。NewSQL 适合确实同时需要事务和水平扩展、而且团队愿意承担分布式复杂度的系统。
下一篇我们聊一个特别容易被混成一锅粥的话题：高可用、备份和容灾，到底分别在解决什么问题。