关系型数据库与NoSQL在事务支持和扩展方式上各有侧重

关系型数据库把事务一致性当命根子，NoSQL则把水平扩展当看家本领，两者在事务支持和扩展方式上走的几乎是两条不同的路。选型时看业务更在意“不出错”还是“扛得住”，答案自然就浮出水面。

事务支持：关系型数据库的“老本行”与NoSQL的“轻量化方案”

ACID是关系型数据库的立身之本

行业共识认为,关系型数据库之所以几十年没被淘汰，靠的就是那套ACID事务模型，原子性、一致性、隔离性、持久性，这四个属性像一个严苛的管家，确保每笔交易要么完整执行，要么干脆不执行。

想象一下银行转账场景,你从A账户扣1000元，往B账户加1000元，中间任何一个步骤断电、报错、并发冲突，关系型数据库都能通过锁机制和回滚日志把数据恢复到之前的状态，这种“宁可不做，不能做错”的脾气，在金融、订单、库存这类场景里就是刚需。

MySQL的InnoDB引擎就是典型代表,它默认支持行级锁，配合事务日志和MVCC机制，能在高并发读写下保证数据一致性，比如电商平台下单时扣减库存，如果两个用户同时抢最后一件商品，关系型数据库会通过行锁让第二个请求等待第一个提交后再执行，从机制上杜绝超卖，这种能力是写入基因里的，不是靠后期打补丁。

NoSQL的BASE模型：牺牲强一致，换性能

NoSQL阵营走的是另一条哲学BASE模型，基本可用、软状态、最终一致，说白了就是允许系统在某一刻数据是“乱”的，但经过一小段时间后最终能自我修复。

MongoDB的文档模型就是个例子,它支持单文档原子操作，比如修改一个用户文档里的多个字段，可以保证原子性，但涉及多个文档的事务，就要依赖复杂的分布式事务框架，性能和可靠性远不如关系型数据库原生支持来得踏实，Cassandra更是干脆，它默认采用最终一致性，写入后读到的可能是旧数据，要过一会才能读到最新值。

这带来的直接好处是没有全局锁,写入可以分散到多个节点并行执行，Redis这类键值数据库甚至为了极致性能，把持久化都放在了次要位置，更别提事务了，在缓存、会话管理、实时计数这些场景里，丢一条记录、延迟几百毫秒同步，用户根本感知不到，但换来的是每秒几十万次的读写吞吐量。

什么时候需要真正的事务

不少开发者会问“关系型数据库和NoSQL怎么选”这类问题，判断标准其实很简单：如果业务逻辑里有“多步操作必须同时成功或同时失败”的硬性要求，比如转账、下单、退款、库存扣减，那就老老实实用关系型数据库，如果业务是把一条消息发出去、记一条日志、更新一个统计数值，单点失败造成的影响可容忍，NoSQL就够用。

像PostgreSQL最近几个版本也开始支持JSON字段和部分NoSQL特性,MySQL也能挂载MongoDB作为缓存层，但底层事务机制仍然是各自的核心分水岭，用关系型数据库强行做海量写入，用NoSQL强行做复杂事务，都属于逆着性子干活，早晚出问题。

扩展方式：纵向扩展的“稳重派”与横向扩展的“激进派”

关系型数据库的垂直扩展路线

关系型数据库的默认扩展方式是纵向扩展,也就是买更强的单机硬件，加CPU、加内存、换SSD硬盘，靠提升单节点算力来支撑更多请求，这种方式的优势是简单，不需要改动应用代码，DBA把配置调优一下，性能就能上去。

但天花板非常明显,一台顶配服务器的价格动辄几十万甚至上百万，而且再强的单机也有物理极限，当数据量达到几亿行，单表查询就算走了索引，全表扫描也可能要几十秒，这时候常见的出路是分库分表，把一张大表按某个字段哈希拆分到多个实例上，可是分库分表会让跨实例的关联查询、事务、全局唯一ID变得异常复杂，等于把数据库的一部分压力转移到了应用层和中间件上，成本并不低。

业界常用的分库分表工具像ShardingSphere、MyCat，虽然能缓解压力，但需要业务代码配合路由规则，而且扩容时往往需要停机或双写迁移，据部分公开技术社区统计，复杂分库分表系统的维护成本，是同等规模单实例的三到五倍，这也是不少团队对关系型数据库既爱又恨的原因。

NoSQL的横向扩展基因

NoSQL天生就是为了水平扩展而设计的,以MongoDB为例，它的分片集群机制允许把数据按片键分散到几十个节点上，增加节点就能近乎线性地提升读写性能，Cassandra的环状结构更是把每个节点都视为对等节点，没有主从之分，写请求可以广播到任意节点，然后通过Gossip协议同步数据。

横向扩展带来的核心优势是存储和计算能力可以弹性伸缩,双十一大促前，运维团队可以快速地把Redis集群从十个节点扩展到五十个节点，活动结束后再缩回来，按需付费，而关系型数据库的扩展往往要提前几个月规划，采购硬件、搭建主从、测试切换，节奏完全跟不上互联网业务的快速变化。

不过NoSQL的扩展也不是免费的午餐,分片键选得好不好，决定数据分布是否均匀，如果选了一个单调递增的字段，比如时间戳，那新数据会全部写入最后一个分片，形成热点，业界的做法是用一致性哈希、加盐、或者选择业务相关性强的字段作为片键，但这对设计者提出了更高的前期要求。

两种扩展方式的实际成本对比

下表从几个维度简单对比：

需要明确的是,这种对比不是绝对的，近几年NewSQL概念兴起，像TiDB、OceanBase这样的分布式关系型数据库，试图同时兼顾ACID事务和水平扩展能力，它们的底层架构借鉴了NoSQL的分片思想，但上层仍提供SQL接口和完整的事务支持，这类产品已经逐步在金融、政务场景落地，但技术门槛和部署复杂度依然比传统单机数据库高出一个量级。

不同场景下的取舍：事务优先还是扩展优先

电商交易链路：必须保住事务底线

在电商平台的下单到支付业务里,订单表、库存表、账户流水表之间的数据关联非常紧密，一个用户提交订单后，系统要扣库存、生成订单记录、锁定优惠券、减少余额，这四步操作只要有一个失败，整个订单就得回滚，即使双十一流量再大，也不能用最终一致性来糊弄，因为用户付了钱却没锁定库存，那是赤裸裸的P0事故。

所以核心交易系统至今仍以MySQL为主,为了应对高并发，架构上采用读写分离、热点商品独立缓存、异步队列削峰等手段，把事务压力控制在最小范围内，像阿里这样的公司，甚至把核心账务拆成多个微服务，每个服务有自己的数据库，通过分布式事务中间件协调，但底层依然保证最终一致的时效性在毫秒级以内。

日志与社交动态：扩展能力是第一位

平台和物联网场景,用户点击行为日志、系统监控指标、传感器上报的数据，这些数据有几个特点：写入量巨大、几乎不需要更新、对一致性要求低，一条日志晚十秒出现在查询面板上，没有任何人会投诉。

这种情况下用关系型数据库存储,不仅性能跟不上，而且存储成本高得吓人，多数团队选择把这类数据放进MongoDB或者Elasticsearch，MongoDB的文档模型适合字段不固定的半结构化数据，扩展时只要增加副本集或分片数量即可，Elasticsearch的分布式索引天然支持海量日志的检索和分析，配合Kibana能快速出可视化报表，这里常见的搜索词是“MySQL和MongoDB对比哪个更适合日志存储”，其实答案很明确：日志场景根本不该用MySQL。

混合架构：让两者各司其职

现实中很少有系统只用一种数据库,比较典型的做法是：核心业务库用MySQL或PostgreSQL，缓存和会话用Redis，海量行为数据用MongoDB或ClickHouse，搜索用Elasticsearch，各数据库通过消息队列或定时任务进行数据同步，发挥各自的强项。

比如一个社区App,用户资料、好友关系、点赞数这些强一致数据放MySQL，动态流和评论列表放MongoDB，排行榜和热门话题缓存到Redis，当用户点赞时，先写MySQL确保计数准确，再异步通知MongoDB更新动态数据，这样既保证了关键数据不出错，又能让非核心功能扛住大流量。

Q&A：关系型数据库和NoSQL的扩展方式对比中常见疑问

问：关系型数据库真的不能水平扩展吗，为什么要用分库分表？

关系型数据库从设计之初就假设是单机存储引擎,所有并发控制、事务日志都基于共享内存和磁盘，水平扩展需要把数据拆分到多台机器，但跨机器的连接查询、外键约束、分布式事务都是关系型数据库的反模式，分库分表是无奈之举，相当于应用层自己实现路由逻辑，把一台数据库拆成几十台来模拟水平扩展，虽然可用，但维护成本高，且无法完全避免跨分片问题，目前TiDB等NewSQL数据库通过分布式存储协议实现了对关系型水平扩展的原生支持，但生态成熟度仍在追赶MySQL。

问：NoSQL有没有可能支持真正的事务，比如ACID？

部分NoSQL产品做了努力,MongoDB从4.0版本开始支持多文档事务，在副本集内可以保证ACID，但跨分片事务的有所保留，性能损耗明显，Google的Spanner和CockroachDB使用全局时钟和事务管理器实现了分布式ACID，但它们本质上更像是分布式关系型数据库，行业专家认为，NoSQL的事务支持属于“有但够用”的水平，适合弱一致性、低频跨节点操作的场景，无法承受银行转账那种高频强事务压力，如果业务的核心诉求是强一致事务，直接选关系型数据库或者NewSQL，不要指望用MongoDB扛核心账务系统。

问：从MySQL迁移到MongoDB的主要难点在哪里？

最大的难点在于数据模型设计思路的转变,MySQL要求先建表定字段，MongoDB则允许同一集合内文档字段不同，这容易让人产生“不用设计表结构”的错觉，没有明确数据访问模式的MongoDB集合后期会非常痛苦，因为无法根据字段建有效索引，原有SQL中的多表关联查询需要改写成嵌入子文档或多次查询，事务处理从原生支持变成谨慎使用，需要梳理哪些业务必须强一致，哪些可以接受最终一致，建议迁移前先用测试数据模拟全流程，同时保留MySQL作为回退选项，常见的数据迁移工具如mongodump和mysqldump各有局限，大型项目一般需要定制同步脚本。

回到最初的问题,关系型数据库与NoSQL并不是谁替代谁的关系，而是取舍路线的不同，核心交易场景下，事务完整性比伸缩性更值钱；海量数据和高并发场景下，扩展能力比数据严谨性更划算，理清业务的底线在哪，数据库选型就成功了一大半。