📚 课程目录第2章 SQL Server版本与许可规划

2. SQL Server版本与许可规划

SQL Server的版本与许可规划，是企业数据库平台建设中最早需要定稿、也最容易在后期引发成本与合规风险的一项决策。它同时受三个维度约束：功能需求（高可用、安全、性能上限）、部署形态（物理机、虚拟机、容器、云托管）、商务与合规（许可模式、核心数、虚拟化授权、审计口径）。三者中任何一项判断失误，都可能导致“功能不够用要升级”或“买了用不上的高级功能”两类浪费。

一、版本选型：先看功能边界，再看价格

当前主流可选版本为 Enterprise（企业版）、Standard（标准版）、Express（免费版）、Developer（开发版），以及面向云端的 Azure SQL 系列。选型的正确顺序是：先用功能硬门槛筛掉不合格版本，再在合格版本中比价格。

关键功能边界如下：

内存与计算上限：Standard 版缓冲池上限约 128 GB，单实例最大可用内存受限；Enterprise 无此限制。若单库热数据超过 100 GB 且要求全内存缓存，Standard 会频繁物理读。
CPU 插槽/核心：Standard 最多支持 4 插槽或 24 核（取较小者），Enterprise 按操作系统上限。
高可用：Standard 支持 Basic Always On（2 副本、1 个可用性数据库、无只读副本）；Enterprise 支持多副本、可读辅助副本、同步提交多副本。
高级能力：列存储聚集索引、内存优化表、数据压缩、分区、透明数据加密（TDE）、细粒度审计、Resource Governor 等，Standard 仅部分支持或完全不支持。
数据库大小：Express 单库上限 10 GB，缓冲池约 1.4 GB，仅适合开发、测试或极小规模边缘应用。

一个常见的误判是：业务方只提“要读写分离”，团队就默认必须上 Enterprise。实际上若只读副本仅用于报表且可接受分钟级延迟，Standard 的日志传送或只读快照也能满足，成本可下降一个数量级。因此选型结论必须写成“功能需求 → 版本门槛 → 备选版本”的推导链，而不是直接报版本名。

二、许可模式：核心许可与服务器+ CAL

SQL Server 提供两种主要许可模式：

模式	适用场景	计量方式	要点
核心许可（Core-based）	互联网应用、虚拟化、无法统计用户数	按物理核心或虚拟核心授权	Enterprise 最少 4 核/处理器，Standard 最少 2 核/处理器；核心数按 2 的倍数购买
服务器 + CAL	内部员工系统、用户数明确	1 台服务器许可 + 每用户/设备 CAL	仅 Standard 及以下支持；用户数增长后成本可能反超核心许可

虚拟化环境是合规风险最集中的区域。核心许可下，若使用“无限虚拟化”权益，需为宿主机全部物理核心购买 Enterprise 许可；若采用“按虚拟机授权”，则每个 VM 需按其分配的 vCPU 数量购买，且单 VM 最少 4 核。很多企业因未区分这两种口径，在审计时被要求补购大量许可。

合规红线：被动故障转移（Failover）场景下，若备用服务器仅在主服务器故障时接管，且不承载其他工作负载，可享受“被动故障转移免许可”权益；但若备用节点同时运行报表、测试或任何可读工作负载，则必须为其购买完整许可。这是审计中最常见的争议点。

三、成本评估：把 TCO 拆成可计算项

成本评估不能只看许可单价，应拆为：许可成本 + 硬件/云资源成本 + 运维人力 + 高可用冗余成本 + 合规风险成本。下面给出一个可复用的估算示例（参数为教学假设，非实测报价）：

场景：核心业务库，峰值 8 核，要求 Always On 可读副本
方案A：Enterprise 核心许可，2 节点各 8 核
  许可核心数 = 8 × 2 = 16 核
  若单价按 1 单位/核·年计，年许可成本 = 16 单位
方案B：Standard 核心许可，2 节点各 8 核
  许可核心数 = 8 × 2 = 16 核
  年许可成本 = 16 × 0.25 = 4 单位（假设 Standard 单价为 Enterprise 的 1/4）
  但需评估：Standard 无列存储聚集索引、无 TDE、只读副本能力受限
结论：若功能门槛可满足，方案B 年成本约为方案A 的 25%；
      若必须使用 TDE 或列存储，则方案B 不可行，成本差异不成立。

云上部署时，成本口径变为“按小时计费的 vCore + 存储 + 备份 + 网络”，且 Azure SQL 提供 DTU 与 vCore 两种模型。评估时应把 3 年预留实例（Reserved Instance）折扣、弹性伸缩收益与本地许可的固定资产摊销放在同一时间轴上比较，而不是比较单月账单。

四、合规要点与落地检查

合规的核心是“可证明的授权覆盖”。建议在平台建设初期就建立许可台账，记录：实例名、版本、许可模式、授权核心数、物理/虚拟宿主、高可用角色、CAL 数量、采购合同编号。每次扩容、迁移、新增只读副本前，先更新台账再执行变更。

实用检查清单：

是否所有运行 SQL Server 的物理核心或 vCPU 都被许可覆盖？
被动故障转移节点是否真的“被动”？有无报表、ETL、测试负载？
Standard 版是否被用于超出其内存/核心/功能上限的场景？
Developer 版是否仅用于非生产环境？有无被误用于生产？
Express 版数据库是否接近 10 GB 上限？
云上 vCore 模型是否与本地许可权益（Azure Hybrid Benefit）正确叠加？

下图把版本选型、许可模式与合规判断压缩为一条可执行的决策路径，便于在方案评审时快速定位当前决策所处位置。