过去几年，云数据库最确定的一件事，是把存储从计算里拆出来。存算分离让计算节点可以像无状态服务一样被替换、扩容与缩容，存储层则依托分布式对象存储或共享存储保证多副本与持久性。当这套架构跑顺之后，一个新的问题自然浮出水面：既然计算已经可以随时来去，那它为什么还要一直开着？
无服务器的本质是弹性粒度下探
无服务器数据库并不是没有服务器，而是把服务器这一层从用户的视野里彻底拿掉。用户面对的不再是规格固定的实例，而是连接地址、容量上限和计费口径。背后的计算资源被池化，由平台按请求量在毫秒到秒级调度，闲时缩到零或接近零，忙时横向铺开。对业务来说，最大的变化是容量规划从提前买够变成事后结算。
三个技术支点
- 日志即数据库：写入先落成持久化日志，计算层只负责日志回放与内存态重建，节点故障后可在别处快速恢复，无需每台计算节点都挂一块盘。
- 计算池化与预热池：平台维护一批已初始化的计算容器，把冷启动从秒级压到百毫秒级，缓解无服务器最被诟病的首请求延迟。
- 存储分层与按需加载：热数据留在本地缓存或高性能层，冷数据沉到对象存储，页面按访问路径懒加载，让体量很大的库也能快速启动。
难在哪里
弹性听起来美好，代价集中在几处。其一是连接模型，传统数据库连接是有状态的，短连接爆发时容易把连接数打满，需要代理层或连接池做转换。其二是事务与一致性，计算节点频繁生灭，对分布式事务提交路径和元数据服务提出更高要求。其三是可观测性，实例生命周期缩短后，指标与日志的关联方式要重新设计，否则排障会变得困难。其四是延迟抖动，缩容到零意味着下一个请求要承担唤醒成本，对延迟敏感的交易类负载未必合适。
落地节奏与选型要点
从公开实践看，无服务器数据库目前更适合三类场景：开发测试与预览环境、流量波动剧烈的互联网业务，以及大量低频访问的多租户库。核心交易库则多采用计算常驻加只读副本弹性的折中方案。选型时值得追问几个问题：缩容到零后的唤醒时间是多少，是否提供预热池；计费的最小单位与边界条件；跨可用区故障切换的恢复目标；是否支持把实例从无服务器平滑迁移到固定规格，避免被架构锁死。
结语
存算分离解决的是资源怎么摆，无服务器解决的是资源什么时候摆。当弹性粒度从实例下探到请求，数据库运维的重心会从容量管理转向使用方式治理：谁能连、连多久、花多少。它不会一夜之间替换掉所有实例型数据库，但正在把按需从一句口号变成可计费的默认选项。