3. 版本与许可选型
SQL Server 的版本与许可选型，是数据平台交付中最容易“先买错、后补救”的环节。它同时受三件事约束：业务需要哪些功能、部署形态是物理机还是虚拟化/云、以及预算按核心还是按服务器计算。本节先厘清版本能力边界，再讲许可计量方式，最后给出一套可落地的选型决策方法。
一、三个常用版本的能力边界
企业版（Enterprise）是功能全集，核心价值集中在高可用、性能与可扩展性：Always On 可用性组支持多个可读辅助副本、在线索引重建、分区表并行度优化、内存优化表与列存储的完整能力、资源调控器、数据压缩与备份压缩、透明数据加密（TDE）、以及面向大规模并发的并行查询与 NUMA 感知。标准版（Standard）保留了数据库引擎、基础高可用（两节点故障转移集群、基础可用性组）、列存储、压缩、TDE 等常用能力，但可用性组副本数、内存与 CPU 上限、并行度与分区能力受限。开发版（Developer）功能与企业版一致，但许可仅限非生产用途，用于开发、测试、演示与培训。
需要特别提醒：SQL Server 2016 SP1 之后，标准版开放了行级安全、动态数据掩码、变更数据捕获、内存优化表等此前仅企业版具备的功能，因此“标准版一定缺某功能”的旧经验已不成立。选型必须以目标版本的实际功能矩阵为准，而不是凭印象判断。
二、许可模式怎么算
企业版只提供按核心授权（Core-based）。规则是：以物理 CPU 核心数为基准，每 2 核为一个授权单位，最低 4 核起售。若部署在虚拟化环境，需要按宿主机全部物理核心授权，除非采用“单虚拟机 + 专用宿主”等微软认可的例外方式。标准版则同时提供按核心与“服务器 + CAL”两种模式：当用户数少、并发低时，服务器 + CAL 往往更省；当用户数多或面向外部用户时，按核心更可控。
高可用场景要单独算账。以两节点 Always On 为例，若购买软件保障（SA），被动副本可享受免授权权利，即只需为主副本授权；若不购买 SA，则两个节点都要授权。因此“企业版 + SA”虽然单价更高，但在多副本架构下可能反而比“企业版无 SA 双份授权”更划算。这一笔账必须在方案阶段算清，而不是等到采购时才发现预算缺口。
三、功能矩阵与选型决策方法
选型不应从“哪个版本便宜”出发，而应从“业务需要哪些能力”倒推。建议按以下顺序推进：
- 列出硬性功能需求。例如是否需要多副本可读、是否需要在线索引重建、单库内存是否超过 128GB、是否需要资源调控器隔离多租户负载。这些是版本分水岭。
- 确认部署形态。物理机、虚拟机还是云托管。虚拟化会直接影响核心授权数量，云上则要区分“自带许可（BYOL）”与“许可含在实例价中”。
- 估算核心数与用户数。按核心模式计算：物理核心数向上取偶数，最低 4 核；按服务器 + CAL 模式则统计实际访问用户或设备数。
- 叠加高可用与容灾成本。是否购买 SA、副本是否免授权、是否需要异地容灾节点，都会改变总成本。
- 用开发版做验证。在采购前用开发版搭建与目标版本一致的环境，验证功能可用性与性能表现，避免“买了企业版却发现用不上”或“选了标准版却卡在功能缺失”。
四、一个可参考的选型判断示例
假设某业务系统：单库数据量约 800GB，峰值并发 300，要求 7×24 运行，允许分钟级故障切换，但不要求只读副本分流；服务器为 2 路 16 核物理机，计划部署在虚拟化平台，宿主机共 32 核。按上述方法判断：不需要多副本可读，单库内存未超过 128GB，无在线重建刚需，因此标准版即可满足。许可按核心计算：宿主机 32 核，每 2 核一个单位，共 16 个单位，最低 4 核起售已满足。若用户数仅 200 人且并发可控，也可评估“服务器 + CAL”模式是否更省。最终结论应写成一句话：标准版 + 按核心授权，两节点故障转移集群，不购买 SA（因无多副本免授权需求）。
把版本能力、许可计量和业务需求三者对齐，选型就不再是拍脑袋，而是一份可解释、可审计、可复用的决策依据。