1.1 三十年演化与版本选择

1.1 三十年演化与版本选择

本节摘要：SQL Server 从 1989 年与 Sybase 的合作项目，演化为今天横跨 Windows、Linux、容器与云的企业级数据平台。本节沿四个时代梳理这条演化线，并落到最实际的问题上：Express、Standard、Enterprise 三个版本的能力边界在哪，选版本人最容易在哪些资源上限上翻车。演化史是理解后续所有章节的坐标系。

从一段借用内核的日子说起

1989 年，微软、Sybase 与 Ashton-Tate 三家合作，把 Sybase 的数据库内核移植到 OS/2 上，这就是 SQL Server 1.0。今天你依然能在这款产品身上找到这段历史的活化石：客户端与服务器之间的 TDS 协议、系统存储过程的命名风格，都带着 Sybase 血统。1994 年两家分道扬镳，微软买断代码逐步自研，但真正的大手术发生在 7.0 版（1998 年发布）：存储引擎整个重写，从此告别 Sybase 时代的页结构，建立了沿用至今的 8KB 页体系。你在第 3 章学到的页、区、文件组，骨架就是那时打下的。

2000 年代是平台化扩张期：2005 版把 Integration Services、Analysis Services、Reporting Services 凑齐了 BI 三件套，数据库产品第一次以"平台"自居。2012 版推出的 Always On 可用性组是高可用史上的分水岭——它把数据库镜像的企业级能力做了重构，支持一个主副本带多个可读副本，第 6 章会花整章讲它。2016 到 2019 这三个版本密集注入了现代能力：Always Encrypted、行级安全、列存储索引成熟、内存优化表、智能查询处理。2017 年是个标志性年份：SQL Server 登陆 Linux，二十八年 Windows 独占被打破。2022 版把"云连续性"做成主题——本地实例与 Azure 之间的链接能力（对象存储直查、托管实例链接、Azure Synapse Link）让本地与云的边界进一步模糊。

版本不是价签，是能力围墙

选版本的本质是认清能力围墙的位置。Express 免费但限制严格：单个数据库最大 10GB，缓冲池约 1.4GB，只能用到较少的核数——它是开发学习与极小场景的工具。Standard 面向中小企业主力负载：数据库大小不限，但缓冲池上限 128GB、内存优化表 32GB，Always On 只支持基本可用性组（两个副本、一个库一组），列存储与分区等高级能力受限或缺失。Enterprise 解除全部能力限制：无限缓冲池、在线索引操作、高级分区、完整 Always On、透明数据加密全功能。Developer 版与 Evaluation 版值得专门记住：前者免费且具备 Enterprise 全部能力但禁止生产使用，是学习和功能验证的利器；后者是 180 天试用。

💡 一个常被忽略的事实：Developer 版功能与 Enterprise 完全一致。怀疑"这个功能是不是我的版本不支持"时，先在 Developer 版验证功能本身，再核对生产版本的能力矩阵，能把"功能不存在"和"版本不支持"两类问题干净地分开。

版本能力差多少，命令行一问便知。下面这条查询是接手任何实例后的第一件事：

SELECT
    SERVERPROPERTY('ProductVersion')  AS 版本号,
    SERVERPROPERTY('ProductLevel')    AS 补丁级别,      -- RTM / SP / CU
    SERVERPROPERTY('Edition')         AS 版本 edition,
    SERVERPROPERTY('EngineEdition')   AS 引擎类型,      -- 1个人 2标准 3企业 8托管实例
    SERVERPROPERTY('IsClustered')     AS 是否集群实例;
-- 输出示例（一套 Standard 实例）：
-- 15.0.4312.2 | CU24 | Standard Edition (64-bit) | 2 | 0
​

办案档案的第一页就记这个：版本号决定你能查哪些 DMV、用哪些功能；补丁级别决定该不该建议打累积更新——2017 之后微软改为每年发布 CU（累积更新）的节奏，不再出 Service Pack，很多已知 bug 只在最新 CU 里修复。

一次版本上限引发的办案

2021 年冬，一家零售企业的订单库开始规律性"变慢"：每天上午十点前后，查询延迟爬升三到五倍，午后自然缓解。值班排查了半天索引和阻塞，都排除。最后翻到资源画像：实例是 Standard，物理机 256GB 内存，但性能计数器显示缓冲池稳定压在 128GB 附近，页面预期寿命（PLE）在高峰期从四位数跌到两位数。真相很简单——Standard 的缓冲池上限就是 128GB，高峰期工作集超出了它能缓存的范围，大量读请求直接砸向磁盘。缓解靠两条：把报表负载挪到只读副本时段错峰，以及中期立项升级 Enterprise。这个案例里没有一条慢 SQL，问题出在版本的能力围墙上。教训是：接手实例先看版本，把资源上限抄进值班手册，否则你会把"版本墙"误诊成"参数病"。

类似的墙还有几堵：Standard 的 CPU 上限（较少的 4 路 NUMA 或 24 核）、Express 的 10GB 单库上限、内存优化表在 Standard 上限 32GB。它们的特点是"报错不明显"——不报错，只是慢。

License 模式：成本账的一半

SQL Server 的商业授权有两条主路：按核心授权（Per Core，按物理核数买断，无用户数限制）与服务器加客户端访问许可（Server + CAL，适合内网用户数明确且少的场景）。2012 之后按核心成为主流，因为它不受用户增长影响。对企业真正有杠杆的是两条省钱通道：一是 Azure Hybrid Benefit，把本地带 Software Assurance 的许可切换到 Azure SQL 上抵扣最高三成以上的费用；二是版本降级重组负载——不是所有库都需要 Enterprise，把报表类负载迁到 Standard 只读副本是常见的降本动作。第 6 章讲上云路径时会把这些账算细。

本节要点回顾

• 四个时代：Sybase 血统、7.0 自研重写、2005 平台化与 2012 Always On、2017 起的云与 Linux 转型——每个时代的能力都叠加在今天的版本里；
• 接手先查版本：用 SERVERPROPERTY 一条查询拿到版本号、补丁级别与版本类型，这是值班手册第一行；
• 版本是能力围墙：Express 的 10GB 与 1.4GB 缓冲池、Standard 的 128GB 缓冲池与 24 核上限，翻墙的表现是"莫名变慢"而不是报错；
• Developer 版免费全能：功能验证用它，别在生产里赌版本能力；
• CU 节奏：2017 起只有累积更新没有 SP，遇到诡异 bug 先查是否已被新版 CU 修复；
• License 有杠杆：按核心与 Server 加 CAL 两条主路，Azure Hybrid Benefit 与负载降级是两条省钱通道。

版本选定了，下一个问题旋即而至：它装在哪——裸机、虚拟机、容器还是云上？下一节把五种部署形态的责任边界画清楚。