存储与计算分离架构把存储和计算彻底拆开，数据库扩容时只需增加计算节点，单机磁盘容量不再是上限，这是解决数据库扩容受限于单机磁盘怎么办这一难题的主流答案。
传统数据库扩容，就像给一个工人不停加桌子，桌子再大，工人手不够长也是白搭，存储与计算分离后，工人和桌子各管各的，活儿多了就加人，桌子满了就加柜子，互不拖累，下面从原理、实操、选型三个层面拆开讲。
数据库扩容为什么总是卡在磁盘上
传统架构里，数据库跑在一台物理机或虚拟机上，数据文件和计算进程共用一个家，扩容时要么升级单机配置，要么做分库分表,但两条路都有死胡同。
- 垂直扩容（升配置）：CPU、内存好加，磁盘却受限于机箱盘位和云盘挂载上限，单块云盘性能有天花板，多块盘做RAID又带来新的运维负担，当你试图把单机磁盘从2TB升到20TB时,迁移数据和重建索引的时间可能比业务容忍极限还长。
- 水平扩容（分片）：把数据拆到多台机器上，听起来很美，但业务代码要改分片键，跨节点查询变慢，事务一致性变复杂，很多团队分片分到一半就后悔，因为数据均衡、扩容再迁移的成本极高。
行业共识认为，传统架构的瓶颈不在于计算力，而在于存储的“粘连”，计算节点和存储节点绑定时，每加一份计算资源，就得被迫加一份用不完的磁盘空间；反之，磁盘不够时，又不得不连计算资源一起买,这种浪费在数据量爆炸的今天尤其刺眼。
存储与计算分离架构的原理：拆家式重构
核心就一句话：把数据放到远端共享存储上，计算节点只负责处理请求，两者通过网络连接，每个计算节点都是“无状态”的,启动后挂载同一份数据即可干活。
数据不搬家，只加计算节点
假设你有一个电商库，订单表数据已经占了5TB，传统架构下，要扛住大促流量，你得买一台磁盘更大的机器，把5TB数据拷过去，再切换连接，存储与计算分离后，数据在共享存储池里待着，新加一台计算节点，几分钟内就能读取同一份数据，不需要拷贝、不需要停机。
计算节点扩缩容按分钟计
因为计算节点不存数据，扩容就是启动新实例、挂载存储卷、加入集群三个动作，缩容更简单，直接摘掉实例即可，业务流量波峰波谷明显时，这种弹性让数据库使用成本直降，业内专家指出,这种架构在云数据库领域已是大势所趋。
存储层单独扩展，容量和性能互不干扰
存储池可以独立加盘，容量满了就扩存储节点，性能不够就加SSD或者升IOPS，计算层和存储层各自伸缩，谁缺补谁，比如日志类业务，数据量大但查询少，你可以只扩存储，不增加计算节点；分析型业务CPU密集，就多上几个计算节点,存储保持原样。
存储与计算分离架构怎么选型：三种主流形态
市面上号称支持这种架构的产品不少，但落地形态有差异,选型前先看清楚自己属于哪一类。
- 云原生数据库（如PolarDB、TDSQL-C）：存储基于分布式云盘，计算节点共享一份数据，开启“Serverless”模式后，扩缩容自动完成，适合流量不可预测的业务,这类产品的价格通常按计算规格和存储用量分开计费。
- 自建分布式存储+开源数据库：用Ceph或MinIO搭共享存储，再跑多个MySQL或PostgreSQL实例挂载同一卷，成本可控但运维门槛高，需要自己处理锁、一致性、failover等问题,适合有专业DBA团队的公司。
- 计算存储分离的分布式数据库：底层用对象存储或HDFS，上层跑TiDB或StarRocks这类原生支持存算分离的引擎，适合海量数据分析场景，扩容自动均衡,但事务型业务要评估延迟。
选型时别只看官网宣传，要拿自己的真实负载做压测,重点观察三条：
- 网络延迟是否在可接受范围（万兆内网和跨机房效果完全不同）
- 存储计费方式是按量还是预置，突发流量时账单会不会失控
- 故障切换时，新的计算节点能否无缝接管，数据会不会丢
实际部署操作：从传统架构迁过去要几步
以自建MySQL迁移到云原生存算分离实例为例,基本流程如下：
- 准备阶段：先建一个最小规格的存算分离实例，用DTS或DataX把老库全量数据同步过去,同时开启增量同步。
- 校验数据：比对源库和目标库的表行数、主键自增值、关键业务表的checksum,确认没有偏差。
- 流量切换：在一个维护窗口内，停写操作，等增量追平，把应用连接串切到新实例,再恢复写入。
- 回滚预案：保留旧实例7天，一旦新库有慢查询或锁冲突,立刻把连接切回去。
如果是自建Ceph方案，步骤会多一些：先装Ceph集群，创建RBD块设备，格式化成文件系统，挂载到多个计算节点上，但要注意，多个MySQL实例同时挂载同一块设备，需要启用共享锁机制（如用Drupal或gfs2），否则会损坏数据，这块技术坑很深,没有成熟脚本别轻易尝试。
对比传统架构：性能、成本、运维的差异
| 维度 | 传统单机架构 | 存储与计算分离架构 |
|---|---|---|
| 扩容操作 | 停机迁移或分库分表改代码 | 加节点/加存储，分钟级生效 |
| 存储利用率 | 每台机器自带磁盘，浪费较多 | 存储池共享，利用率高 |
| 成本模型 | 计算和存储绑定购买，易超配 | 分开计费，各花各的 |
| 运维复杂度 | 数据迁移、分片管理费人力 | 依赖云平台或分布式存储技术 |
| 故障恢复 | 单机故障需重建实例 | 计算节点无状态，快速替换 |
性能上，存储与计算分离引入了网络IO，比本地盘延迟高一些，但对于大多数中低并发业务，差距在毫秒级以内，感知不明显，真正影响性能的是存储层的IOPS上限,选购时看清云盘的性能等级。
成本方面，传统架构买32核64GB的实例，往往为了那5TB磁盘掏了不必要的钱，存算分离下，你可以租一个16核32GB配上3TB存储，不够再加存储，单月账单明显下降，很多云厂商的存储与计算分离价格看起来贵，但算上传统架构里闲置的计算资源,实际上更划算。
什么样的业务最适合这种架构
不是所有数据库都需要存算分离,下面几类场景收益最大：
- 流量波峰明显的业务：活动大促时几十倍流量冲击，平时低负载，存算分离可以缩到1个节点,大促前提前扩到10个节点。
- 超大存储数据集：单表突破TB级别，传统垂直扩容已经买不到合适磁盘,分片又太复杂。
- 多环境共用数据：开发、测试、预发环境需要查询同一份生产数据（脱敏后），存算分离让多个实例挂同一个存储快照,省下大量副本空间。
- 读写分离需求高：读扩展直接加只读计算节点，写节点保持唯一，数据同步由存储层自动完成,不用搭Binlog复制链路。
反之，如果数据量很小（几百GB以内）、并发极低、对延迟极其敏感（比如高频交易）,传统单机架构更简单可靠。
存储与计算分离的未来：云原生数据库的标配
数据库扩容受限于单机磁盘的时代正在过去，各大云厂商的新一代数据库产品几乎全部基于存算分离设计，自研数据库也在快速跟进，未来数据库的竞争焦点不再是单机性能,而是存储层的分布式算法和计算节点的调度效率。
对开发者来说，理解这种架构不只是为了扩容，它能改变你设计数据表的思路不用再担心单表数据量过大而强行分表，也不用为了省磁盘空间而删除历史数据，把扩缩容交给平台，把精力留在业务逻辑上,这才是数据库技术演进的真正价值。
Q&A：数据库存储与计算分离常见问题
存算分离后，数据安全怎么保障？
存储层通常采用多副本机制，同一份数据在不同物理机上保留多个副本，单块磁盘故障不会丢数据，计算节点本身不存数据，即使被攻破，拿到的也只是缓存碎片，无法拖走整个数据库，云厂商还会提供静态加密和传输加密,密钥由用户管理或KMS托管。
存算分离架构会不会让查询变慢？
查询延迟主要取决于网络往返和存储IOPS，同地域内网延迟通常在0.1ms级别，加上存储网络协议开销，整体比本地盘多0.5-1ms，对OLTP业务来说，这种差距可以接受；对OLAP大查询，反而是优势多个计算节点可以并行扫描同一份数据，整体吞吐远高于单机，如果你的业务对延迟极度敏感，可以要求云厂商提供本地缓存加速,部分产品支持在计算节点上配置NVMe缓存热数据。
迁移到存算分离数据库要改业务代码吗？
完全兼容MySQL或PostgreSQL协议的产品不需要改代码，连接串换一下就行，分布式数据库如果用的是非标准SQL方言，就需要改一部分，建议迁移前先用兼容性工具扫描一遍SQL语句，重点关注分区表语法、存储过程、自定义函数这三类常见不兼容点。