1.2 部署形态全景：从本地到云的五种形态

1.2 部署形态全景：从本地到云的五种形态

本节摘要：同一个数据库引擎，可以跑在你机房的服务器上、公司的 Linux 主机上、运维部的容器集群里，也可以直接交给 Azure 托管。本节把本地 Windows、本地 Linux、容器、Azure 虚拟机、Azure SQL 数据库与托管实例六种形态摆上同一张桌，用一张"责任分担矩阵"讲清每种形态下备份、补丁、高可用归谁管。选形态本质上是选"你愿意亲自动手的事的清单"。

先把结论摆出来：形态决定谁干活

上一节选定了版本，接下来必须回答"引擎放在哪、谁来管"。这不是纯技术问题，而是责任划分问题。一条有用的判断线：越靠云原生的形态，平台接管的事越多，你的自由度越少。Azure SQL 数据库里你不能自己停服务、不能指定文件路径、不能碰实例级配置，换来的是补丁、备份、高可用全自动；本地部署恰好相反——一切归你，包括凌晨起来做故障切换。

-- 判断自己正处在哪种形态：引擎类型返回值是线索
SELECT SERVERPROPERTY('EngineEdition') AS 引擎类型;
-- 1 = Personal/Desktop 版（仅旧版）
-- 2 = Standard 本地版
-- 3 = Enterprise 本地版（含 Linux、容器、Azure 虚拟机——它们引擎层面与本地一致）
-- 4 = Express
-- 5 = Azure SQL Database（数据库级隔离）
-- 8 = Azure SQL 托管实例（近全兼容本地）
​

这段查询是办案的第一步取证：同一条 SQL 在不同形态上行为可能不同，先确认自己站在哪种形态上，再谈排错。

五种形态逐一过堂

本地 Windows 部署是最大存量：功能完整、与 Windows 认证和域体系深度整合，代价是补丁、备份、高可用全要自己扛。本地 Linux 部署（2017 起）让 SQL Server 进驻开源阵营的机房，适合已有 Linux 运维体系的团队；能力上与 Windows 版几乎对齐，缺的主要是部分集成组件（如某些老版本对全文 Win 认证的限制），文件系统路径风格与脚本生态换成 Linux 的一套。容器部署把实例打包成镜像，秒级拉起、环境一致，是 CI 测试环境的神器；生产上要留意数据卷持久化与状态集管理，Kubernetes 部署Operator 是现在的标准姿势。Azure 虚拟机上的 SQL Server本质还是"你来管的本地版"，只是机房换成了云——License 可以按用量付费或自带许可，OS 与数据库的补丁高可用仍归你。Azure SQL 数据库（单一数据库与弹性池）是数据库级 PaaS：平台管实例，你管库内对象与查询性能，兼容度约在常规 T-SQL 范围内，但实例级功能（如 SQL Agent 部分作业类型、跨库查询的旧写法）受限。Azure SQL 托管实例是给"整库搬家"准备的形态：实例级代理作业、跨库查询、服务中介等本地能力基本齐备，官方定位就是本地实例迁移的着陆区。

六种形态的能力与责任边界，下面这张图按"谁管什么"一目了然。

图 1-2 五种部署形态的责任分担

一线办案笔记：两种形态的两种翻车

第一桩发生在容器上。测试团队用容器拉起 SQL Server 跑接口自动化，一周后数据库"神秘清零"——容器重建时没挂数据卷，所有数据随容器层消失。修复只需把数据目录挂到持久卷上，但暴露的思维定势是：把"环境一致性"当成了"数据持久性"，这两件事在容器世界里毫无关系。

第二桩发生在 Azure SQL 数据库上。从本地迁来的报表作业半夜跑超时，DBA 想加 Max Server Memory 调内存，发现根本没这个配置——PaaS 形态下内存由平台按服务层级分配，能调的是数据库的服务目标（比如把 S3 升到 S4）或改写查询。最终解法是给报表加资源治理标签并错峰，而不是调实例。这两个案例合起来说明：换形态先换心智模型，把本地那套操作惯性原样搬过去，是上云初期事故的主要来源。

云原生集成的当代答案：把控制面延伸到任何地方

云原生不等于"搬去云上"，还有一种中间态：实例留在本地或任意云，但把监控、合规、补丁评估的控制面交给云。Azure Arc 就是这个思路——本地实例登记进 Arc 后，可以在统一面板上看补丁状态、配置基线与安全评估，混合环境不再靠 Excel 台账管理。对多数国内企业，更现实的路径是用类似思路自建：配置基线脚本化、巡检作业集中化、监控指标汇入统一平台。形态可以混合，管控必须收敛到一处——这是多形态并存时代的运维底线。

形态选错的三个早期信号

形态决策做完不代表万事大吉，三个早期信号提示你可能选错了：其一，巡检清单大量失效——迁移到 PaaS 后还在跑本地那套备份校验与补丁巡检，作业全部"成功"却毫无意义，说明心智模型没换；其二，License 与用量错配——Azure 虚拟机上按需付费跑着常年满载的库，比自带许可还贵，账要每季度重算；其三，技能错配引发的救火——团队只会 Windows 运维却选了容器形态，每次故障都在学新工具。三个信号凑齐两个，就该启动形态复审，把"迁移成本"与"维持错配的隐性成本"放上天平重新称一次。
复审时最有用的一张表是"事项归属清单"：把备份、补丁、高可用、监控、密钥、审计六件事逐一标注"平台管"还是"我管"，两边都不沾的事项就是风险敞口——多数形态事故都源于某个事项在迁移时两边都以为对方管了。

本节要点回顾

• 形态是责任划分：从本地到托管实例，平台接管的越多，你的自由度越少，选形态先盘"愿意亲手做哪些事"；
• EngineEdition 是第一取证：5 是 Azure SQL 数据库、8 是托管实例，同一 SQL 行为可能随形态不同；
• 容器的数据持久性靠卷：环境一致性与数据持久性是两件事，测试环境也要挂数据卷；
• PaaS 没有实例旋钮：Azure SQL 数据库调不了 Max Server Memory，性能治理要在库内做或升服务层级；
• 托管实例是迁移着陆区：实例级功能近全保留，适合整实例搬家而非单库外迁；
• 混合形态要收敛管控：Arc 类控制面思路（无论自建还是用云）是多形态时代的运维底线。

形态定了，成本与适配的最后一关是横向对比：同样的需求，Oracle、PostgreSQL、MySQL 能不能更便宜、更好用？下一节把四大关系库放上同一张桌。