◈ DB 选型参考
← 返回首页

Microsoft SQL Server

关系型 OLTP #商业闭源 #T-SQL #Windows生态 #AlwaysOn #按核授权 #纵向扩展 #Azure

微软的商业关系型数据库旗舰，Windows/.NET 生态的事实标准 OLTP 数据库；以 T-SQL、SSMS 工具链、Always On 高可用和纵深安全栈见长，授权复杂度与按核成本是选型时必须正面回答的问题。

用 AI 深挖这款：
证据等级：官方文档 厂商口径 社区实测 社区共识 待验证

基本信息

项内容
厂商Microsoft（美国）
起源1989 年与 Sybase 合作起步，SQL Server 7.0（1998）/ 2005 重写后成为独立产品线，30+ 年演进
许可证商业闭源；Express / Developer 免费（Developer 仅限非生产）
托管服务Azure SQL Database、Azure SQL Managed Instance、SQL Server on Azure VM；2025 起支持 Azure Arc 纳管与按量计费（PAYG）
主类型关系型（OLTP 为主）
兼具类型OLAP（列存索引）、向量检索（2025 原生 vector + DiskANN）、JSON 文档（2025 原生 JSON 类型）
一致性模型单机强一致（ACID）；Always On 同步提交副本 RPO=0
复制协议非共识协议：日志流复制（Always On AG 日志 hardening）、共享存储故障转移（FCI）、日志传送

硬维度（47 项）

1 静态加密 / TDE 有

有。TDE 加密数据文件与事务日志文件；实例上任一库开启 TDE 则 tempdb 自动被加密；TDE 库的备份天然带加密。密钥管理：master 库证书/非对称密钥 → DMK → SMK 层级，可用 EKM 提供程序或 Azure Key Vault（BYOK）。另有 Always Encrypted（客户端列级加密，DBA 也看不到明文；secure enclave 支持密文上有限计算）、备份加密、动态数据掩码。证据：官方文档

2 TLS / 传输加密 有

有。支持 TLS 1.2/1.3，可强制加密连接（ForceEncryption）；2025 起默认 Encrypt=True、TDS 8.0 走 TLS 1.3（第三方资料，细节待验证）。证据：官方文档为主

3 审计 有

有。SQL Server Audit（服务器/数据库审计规范），可写文件、安全日志、应用日志；Azure SQL 可审计到 Log Analytics/Storage。证据：官方文档

4 认证与权限 有

有。Windows 认证（Kerberos/NTLM）、SQL Server 登录、2025 起 Entra ID（含 Azure Arc 托管标识）；服务器角色/数据库角色/架构级权限，另有行级安全（RLS）。证据：官方文档

5 备份恢复 有

有。原生 BACKUP/RESTORE：完整/差异/日志备份、压缩备份、加密备份、备份到 URL（Azure Blob）；日志链支持时间点恢复（PITR）。限制：备份只能还原到同版本或更新版本，不可降级还原。证据：官方文档

6 可观测性 有

有。DMV/DMF（sys.dm_os_wait_stats 等等待统计是 DBA 母语）、Extended Events、Query Store（2022 起新库默认开启）、SSMS；Azure Arc 提供最佳实践评估。证据：官方文档 + 社区共识

7 连接模型 有

有。TDS 协议；连接池在客户端驱动侧（ADO.NET 连接池），服务端按 worker 线程调度；版本按内存/CPU 上限约束并发能力。证据：官方文档 + 社区共识

8 事务与隔离级别 有

有。完整 ACID；默认 READ COMMITTED 是加锁读（读写互阻塞），RCSI/快照隔离需显式开启（代价是 tempdb 版本存储）；支持保存点；Windows 上支持 DTC 分布式事务。证据：官方文档

9 复制与一致性 有

有（见基本信息）。同步提交要求备库日志 hardening（落盘，非重做）才返回，主库提交延迟 = 网络 RTT 税；异步提交主库不等确认，允许备库落后。证据：官方文档

10 扩展方式 部分支持（纵向为主）

部分支持（纵向为主）。Enterprise 单实例 CPU/内存无上限（只受 OS 限制）；横向能力有限：可读副本（备库只读分流）、分布式 AG、手动分片。Standard 版单实例限 32 核/256GB 内存（2025 版官方口径）。证据：官方文档

11 兼容性 有

有。T-SQL 方言（与 Sybase 有历史渊源）；不兼容 MySQL/PG/Oracle 协议；SSMA 提供从 Oracle/MySQL/DB2 的迁移评估与转换。证据：官方文档

12 许可证与商业模式 有（商业闭源）

有（商业闭源）。Enterprise 仅按核；Standard 按核或 Server+CAL；Express/Developer 免费（Developer 禁生产）；Azure 上按 vCore/DTU/Serverless 计费，Arc 纳管支持 PAYG；Software Assurance 带来许可移动性与虚拟化权益。价格只询价，不引用标价（见文末授权核对清单）。证据：官方文档 + 第三方授权指南

13 中文资料丰富度 有（丰富）

有（丰富）。官方中文文档齐全，中文博客/社区实践帖大量。证据：社区共识

14 性能与延迟特征 有

有（企业级 OLTP 标杆；许可按核计费）。

  • 单机 OLTP 与 Oracle 同级讨论；Always On 读扩展；列存索引加速分析 社区共识。
  • 内存优化表（In-Memory OLTP）适合特定高并发场景，但有诸多限制 官方文档。
  • 许可按核计费，性能/成本比常被吐槽；Linux 版性能与 Windows 版接近 社区共识。

15 合规与认证 有

有（继承微软合规体系；中国区由世纪互联运营）。

  • 微软：SOC2、ISO27001、PCI DSS、HIPAA 等厂商口径厂商口径。
  • Azure 中国区（世纪互联运营）：等保测评 厂商口径。
  • 本地部署版合规责任在用户方 社区共识。

16 成熟度与社区生态 有

有（1989 年诞生；微软生态的基本盘）。

  • 1989 年与 Sybase 合作诞生；2016 年推出 Linux 版 社区共识。
  • .NET/Windows 生态基本盘极大，企业存量多 社区共识。
  • 云趋势下新增份额被云原生分流，但存量迁移需求稳定 社区共识。

17 标杆用户 有

有（微软系企业/政府的基本盘）。

  • .NET/Windows 系企业、政府机构存量极大 社区共识。
  • ERP/OA 等传统应用软件的默认搭配 社区共识。
  • 新增互联网项目少，多为存量与迁移 社区共识。

18 生态工具链 有

有（SSMS/SSIS；微软全家桶）。

  • 管理：SSMS；ETL：SSIS；备份：完整/差异/日志内置 社区共识。
  • CDC：内置 CDC/Change Tracking 官方文档。
  • 迁移：DMA（Data Migration Assistant，SQL Server→Azure）官方文档。

19 云托管与 Serverless 有

有（Azure SQL（Managed Instance/Serverless）；RDS）。

  • Azure SQL Database（Serverless 按量）/ Managed Instance 官方文档。
  • AWS RDS for SQL Server 厂商口径。
  • 本地版许可模式与云差异大，注意对准 社区共识。

20 数据接入与摄入 有

有（bcp/BULK INSERT/SSIS，传统强项）。

  • bcp、BULK INSERT、SSIS 是标准批量通道 官方文档。
  • Azure Data Factory 做云上 ETL 官方文档。
  • 大批量注意锁升级与日志增长 社区共识。

21 外部数据访问 有

有（PolyBase 外部表；Linked Server）。

  • PolyBase 可建外部表查 Hadoop/S3/Oracle/MongoDB 等 官方文档。
  • Linked Server 做实例间联邦查询（老但好用）社区共识。
  • OPENROWSET 做临时的外部文件查询 官方文档。

22 CDC 与下游同步 有

有（内置 CDC 功能；Change Tracking；Debezium）。

  • 内置 CDC（基于日志读取作业）+ Change Tracking 两种机制 官方文档。
  • Debezium SQL Server 连接器成熟 社区共识。
  • CDC 作业延迟与清理策略是运维点 社区共识。

23 TTL 与数据生命周期管理 部分支持

部分支持（分区切换+SQL Agent；Stretch 已弃用）。

  • 分区切换（SWITCH）实现快速过期，SQL Agent 定时作业 官方文档。
  • Stretch Database（冷热分层到 Azure）已弃用，不要再规划 官方文档。
  • 无原生行级 TTL 社区共识。

24 在线 DDL 与 Schema 演进 部分支持

部分支持（类2在线索引限企业版；类1/3/4部分在线，DDL 可回滚）。

  • 类1·只改定义：加可空列是元数据级、瞬时完成 社区共识；2012+ 企业版加带运行时常量默认值的 NOT NULL 列也是元数据级在线 官方文档；非常量默认值（如 NEWID()）加列全程 Sch-M 离线 官方文档。
  • 类2·重写数据位置不变：改列类型通常离线重写、全程 Sch-M 社区共识；在线建/重建索引（CREATE/ALTER INDEX … ONLINE=ON：后台构建+增量追踪+原子切换）仅企业版 官方文档；2017+ 支持可暂停恢复（RESUMABLE） 官方文档；XML/空间索引只支持 ONLINE=OFF 官方文档。
  • 类3·搬数据：加/删 PK/UNIQUE 约束（聚簇键变更）支持 ONLINE=ON（企业版；2019+ 可 RESUMABLE） 官方文档；重建聚簇索引会连带重建所有非聚簇索引 社区共识。
  • 类4·验证约束：WITH CHECK/NOCHECK 分阶段（先 NOCHECK 上线、后 CHECK 全表验证） 官方文档；加约束本身可 ONLINE=ON 官方文档。
  • 规模：类2/4 代价 O(n)；在线重建需额外空间（目标索引副本+临时映射） 社区共识。
  • 语义：DDL 可放入事务回滚 社区共识；在线操作主体阶段只持 IS 锁，起止短暂 S/Sch-M 官方文档；长事务的 Sch-S 会卡住 DDL 的 Sch-M，WAIT_AT_LOW_PRIORITY 可缓解 官方文档；标准版无在线索引能力（可用 REORGANIZE 替代） 社区共识。依据版本：SQL Server 2022/2025 文档。

25 多租户与资源隔离 有

有（Resource Governor，租户级管控）。

  • Resource Governor 按 workload group 限 CPU/内存/IO 官方文档。
  • 配合 Resource Pool，租户 QoS 能力完整 官方文档。
  • 配置复杂，调优门槛高 社区共识。

26 跨地域多活 部分支持

部分支持（Always On AG 跨区可配）。

  • AG 可跨子网/跨区，异步提交做容灾 官方文档。
  • 同步提交跨区延迟高，生产多用异步 社区共识。
  • 分布式 AG 可做多写，复杂 官方文档。

27 高可用架构与 RTO/RPO 有

有（Always On AG，自动切换成熟）。

  • AG 自动故障转移，RTO 秒到分钟 官方文档。
  • 同步提交 RPO=0，异步有延迟 官方文档。
  • 见证/仲裁配错会脑裂或无法切换 社区共识。

28 行级安全与数据脱敏 有

有（原生RLS+动态数据脱敏）。

  • SQL Server 2016+ 提供原生行级安全（CREATE SECURITY POLICY + 谓词函数） 官方文档
  • Dynamic Data Masking 支持列级脱敏（default / email / partial / random 四类掩码），可对特权用户配置豁免 官方文档
  • 列级权限通过 GRANT / DENY 到列实现；Always Encrypted 属客户端加密，是另一维度能力 官方文档
  • DDM 的绕过面：db_owner 等高权限默认可见原文，应用须用低权限账号连接才有意义 社区实测

29 JSON 与半结构化能力 有

有（JSON 函数层；无原生类型）。

  • 2016+ JSON 函数（FOR JSON/OPENJSON），存 nvarchar，无原生 JSON 类型 官方文档。
  • 计算列+索引可加速路径查询 官方文档。

30 全文检索能力 有

有（Full-Text Search；中文分词器）。

  • Full-Text Search，中文 word breaker 官方文档。
  • 全文目录维护与备份恢复联动，运维注意 社区实测。

31 存储效率与压缩 有

有（行/页压缩+列存索引+备份压缩）。

  • 内置行级与页级压缩（ROW/PAGE），以及 Unicode 压缩；备份压缩为标准功能。官方文档
  • 列存储索引（Columnstore）提供分析负载下的高压缩比与向量化执行。官方文档
  • 压缩为数据库级/表级选项，开启后对 CPU 有可度量的额外开销。社区实测

32 开源协议与厂商锁定风险 有

有（微软商业闭源；T-SQL 生态绑定深）。

  • SQL Server 为微软商业闭源产品，按核心数授权，版本间功能差异与授权绑定。官方文档
  • T-SQL、SSIS/SSRS、Always On 等专有生态使迁移出成本高。社区共识
  • Azure SQL 系列进一步绑定 Azure 云；Linux 版与容器版存在但仍是商业授权。厂商口径

33 查询优化器与计划稳定性 有

有（CBO+Query Store 强制；自动修正）。

  • CBO + hint（OPTION/USE PLAN），Query Store 可强制/冻结计划 官方文档。
  • Automatic Plan Correction 自动回退退化计划 官方文档。
  • 计划翻转治理在商业库中最成熟一档 社区共识。

34 参数调优与自治能力 部分支持

部分支持（参数精简；自动调优可建索引）。

  • 参数相对精简，automatic tuning 可自动创建/删除索引 官方文档。
  • Query Store+扩展事件诊断完善 官方文档。
  • 深度调优仍需 DBA 社区共识。

35 静默数据损坏防护 有

有（CHECKSUM 页校验+DBCC 完备）。

  • 页校验选项 CHECKSUM 在页写入时生成校验值、读入时验证。官方文档
  • DBCC CHECKDB 可主动全库校验逻辑与物理完整性，是标准运维动作。官方文档
  • 损坏页可从备份做页级还原，无需整库恢复。官方文档

36 存储过程/触发器/过程语言 有

有（T-SQL 完备，SSMS 调试）。

  • T-SQL 存储过程、触发器、CLR 完备，SSMS 调试 官方文档。
  • 去 O 迁移 T-SQL 与 PL/SQL 双向改写成本都高 社区共识。

37 约束与数据完整性 有

有（外键/CHECK/唯一/默认完备）。

  • 外键、CHECK、唯一、默认约束完备 官方文档。
  • 大表加约束注意锁与在线操作 社区实测。

38 分析 SQL 完备性 有

有（T-SQL 分析函数完备）。

  • 窗口函数、CTE、GROUPING SETS 完备 官方文档。
  • 列存索引（columnstore）加持分析性能 官方文档。

39 被遗忘权与数据擦除 部分支持

部分支持（手动DELETE；事务日志/备份残留）。

  • 删除靠 DELETE / TRUNCATE，无原生被遗忘权工作流或擦除证明 官方文档
  • 事务日志备份、完整备份、temporal table（系统版本化表）的历史行都会保留被删数据，temporal 表需单独清理历史 官方文档
  • Always Encrypted 下销毁列主密钥可实现“加密擦除”，但这是密钥管理手段而非标准流程 社区共识

40 数据血缘与目录集成 部分支持

部分支持（Purview 集成；原生有限）。

  • Microsoft Purview 做血缘与目录 官方文档。
  • 数据库原生血缘能力有限 社区共识。

41 存算分离 vs 存算一体 有

有（传统存算一体；Hyperscale 分离）。

  • 传统部署本地盘存算一体 官方文档。
  • Azure Hyperscale 采用存算分离 官方文档。

42 多模能力 部分支持

部分支持（关系+JSON+全文+空间+图；向量待验证）。

  • JSON、全文、空间、图（2017+）官方文档。
  • 原生向量支持待验证 待验证。

43 FinOps 成本可观测性 不适用

不适用（许可证采购模式，无按量计费概念）。

  • 传统按核心/ CAL 许可证采购，成本是采购费+硬件+DBA 人力，无云式按量账单。社区共识
  • Azure SQL 等云托管版按量计费，支持标签归因与预算告警。厂商口径

44 驱动与多语言生态 有

有（mssql-jdbc/ODBC/SqlClient 完备）。

  • 官方 JDBC、ODBC、SqlClient（.NET）完备 官方文档。
  • 微软生态驱动质量高 社区共识。

45 物化视图 有

有（索引视图自动维护+改写）。

  • 索引视图（indexed views）自动维护、查询自动改写 官方文档。
  • 限制多（SCHEMABINDING、确定性函数），滥用拖慢写入 社区实测。

46 支持跨云 部分支持

部分支持（自建版任意云；Azure SQL 绑定 Azure）。

  • 自建 SQL Server 任意云/本地可部署 官方文档。
  • Azure SQL Database/Managed Instance 绑定 Azure 官方文档。
  • 授权跨云（License Mobility）规则复杂 社区共识。

47 热点数据更新能力 部分支持

部分支持（内存优化表乐观冲突，失败靠应用重试）。

  • 磁盘表并发原语：行/键/页级锁，后来者阻塞等待；单条语句持锁数超阈值（默认 5000）触发锁升级为表锁，热点表可能整体串行化；死锁由内核检测并选择牺牲者回滚，重试由应用负责 官方文档。
  • 优化锁（SQL Server 2022+）：写操作持有短周期的 TID 锁而非持有到事务结束，减少锁内存占用与阻塞；但高冲突下同行并发更新仍可能形成 TID 锁死锁，需应用重试并保持一致的更新顺序 官方文档。
  • 内存优化表：乐观并发、无锁无闩锁，读写互不阻塞；两个事务并发更新同一行时一个成功、另一个直接失败报错，重试必须由应用显式实现；官方明确指出写冲突频繁的负载不适合内存优化表 官方文档。
  • 衰减形态：磁盘表热点行即阻塞点，升级为表锁后拖累整表；内存优化表把"等待"变成"失败重试"，冲突率过高时重试风暴反而拖垮吞吐 社区共识。
  • 应用层模式与代价：短事务、RCSI 减少读写阻塞、队列削峰、计数器分片；内存优化表要求全量改写重试逻辑并重建表（如 SCHEMA_ONLY 等选项），迁移代价高 社区共识。

招牌能力

  1. Always Encrypted（含 secure enclave）：连 DBA 都看不到的列级加密 真本事：应用端驱动加密，密钥不出客户端，数据库内存里出现的是密文；enclave 允许在密文上做有限计算（模糊匹配、范围查询）。 边缘真相：要用它，应用必须改驱动/代码并管理列主密钥（CMK），运维复杂度从 DBA 侧转移到应用侧；enclave 需要 attestation，故障排查时"看不到明文"既是卖点也是排障地狱。适合的是"合规强制且应用可控"场景，不是"一键开启"。
  2. Query Store + 自动计划修正：执行计划的"飞行记录仪" 真本事：持久化保存计划历史与运行时统计，2022 起新库默认开；自动计划修正可在检测到回归时自动强制上一个好计划。 边缘真相：Query Store 本身有捕获与存储开销，高频 OLTP 要调捕获模式与保留期；自动修正只对"稳定可重复 workload"有效，ad-hoc 满天飞的系统里它帮不上忙。基线质量决定一切——没跑满一个业务周期的基线，修正就是瞎修正。
  3. 纵深安全栈：TDE + 审计 + RLS + 掩码 + Ledger 一套配齐 真本事：金融/政企合规要的"静态加密、传输加密、审计、行级权限、防篡改账本"全是第一方功能，不用拼第三方件，这是它相对开源库最硬的差异之一。 边缘真相：功能全不等于默认全开——TDE 证书过期会导致历史备份无法还原（真实事故类），审计写文件要规划存储，Ledger 有写入放大。安全栈的运维税是持续的，买之前先问团队有没有人懂证书生命周期管理。
  4. 2025 的 Optimized Locking（TID 锁 + LAQ）：不改代码的并发提升 真本事：锁在谓词判定之后再获取（Lock After Qualification），大幅减少锁内存与阻塞；Azure SQL 先验证过的技术下放到本地版。 边缘真相：这是 2025 新行为，老 DBA 的阻塞排障肌肉记忆（看 LCK_M_* 等）要更新；是否要求兼容级别 170 待验证。以及它缓解的是锁争用，不是烂 SQL——缺索引的全表扫描照样慢。
  5. 混合云故事：Arc 纳管 + Fabric 镜像 真本事：本地 SQL Server 可被 Azure Arc 统一纳管（清点、评估、PAYG 计费），数据可近实时镜像到 Fabric OneLake 做分析，OLTP 与分析解耦不写 ETL。 边缘真相：Arc 是 agent 依赖，容器里跑的 SQL Server 不支持 Arc 相关能力（官方明确）；Fabric 镜像是"分析加速器"不是"第二活库"，指望它当 DR 是误用。

深水区

深水区一（授权与成本）：按核计费是把双刃剑，CAL 的"多路复用"不省钱

  • 机制：Enterprise 只按核卖，Standard 可选按核或 Server+CAL；有 SA 才允许"按虚机授权"和获得免费被动副本；Azure Hybrid Benefit 可把本地许可折抵到云上。
  • 推到边缘：
    • 虚机上 vCPU 在建虚机时随手给大，授权数虚胖 15–30% 是第三方审计里的常见发现——分配的核，不是用的核，决定账单。
    • CAL 模式下，应用经中间层连接不能减少 CAL 数量（多路复用规则），最终用户数照算；互联网应用基本只能选按核。
    • 被动副本"免费"的前提是 SA 在有效期内且副本真正被动（可读副本不算被动），很多团队的"高可用"最后在授权审计里变成"要补钱"。
    • Developer 版功能与 Enterprise 完全一致但禁生产——开发/测试环境误用生产许可是 SAM 审计重灾区。
  • 选型含义：询价前先做"计量边界核对清单"（见文末）；核心数/CAL 数/SA 状态三个变量任一个没对齐，报价单都失真。授权复杂度本身就是 TCO 的一部分。

深水区二（复制与容灾）：Always On 的自动故障转移比想象中苛刻

  • 机制：同步提交 = 主库等备库日志 hardening（落盘）才提交；自动故障转移要求：主备均为同步提交 + 自动故障转移模式 + 备库处于 SYNCHRONIZED + WSFC 仲裁正常 + 满足灵活故障转移策略。
  • 推到边缘：
    • 仲裁丢了，整个 AG 不会自动切——仲裁是比 AG 更大的单点，脑裂靠"多数派仲裁"防，但代价是少数派分区直接停写。2025 增强了仲裁丢失后的恢复逻辑官方文档，防止库卡在 Not Synchronizing，但这只是"恢复更快"，不是"不丢仲裁也能切"。
    • 异步提交的唯一故障转移方式是强制故障转移（可能丢数据），且只能手动——DR 演练时 DBA 必须亲手按按钮，RTO 里要算上"人"的时间。
    • 同步备库的 redo 队列是隐形杀手：备库重做跟不上时，故障转移时间被 redo 拖长，RPO=0 不等于 RTO 小。
    • Standard 版只有 Basic AG（2 节点、每组 1 个库），完整 AG 是 Enterprise 专属——"高可用"三个字在两个版本里不是一个东西。
  • 选型含义：AG 方案评审要画仲裁拓扑（见证放在哪），压测要测备库 redo 延迟，RTO 承诺要含"人肉决策"时间。

深水区三（存储与并发）：TempDB 是全实例的共享税，锁升级是隐形阻塞源

  • 机制：TempDB 被所有会话共享（排序、溢出、版本存储、临时表），分配页 PFS/GAM/SGAM 是全局串行点；单语句持锁超约 5000 个会触发锁升级（行锁→表锁）。
  • 推到边缘：
    • 高并发 OLTP 下 TempDB 分配页出现 PAGELATCH_EX 等待，经典解法是"文件数 = 逻辑 CPU 数（上限 8）+ 等大文件"；2022 起 tempdb 元数据优化与 GAM/SGAM 增强缓解了争用，但版本存储（RCSI/快照的代价）依然住在 TempDB——开了 RCSI 就要给 TempDB 留 IO 预算，这是拆东墙补西墙。
    • 一个批量 UPDATE 突然阻塞整张表的无关查询：大概率是锁升级过了 5000 阈值。NOLOCK 能绕开阻塞，但代价是脏读 + 页分裂导致的丢行/重行（正确性 bug，不只是"读到旧数据"）。
    • 2025 的 LAQ/TID 锁缓解锁争用，但改变的是"锁什么时候拿"，拿不拿、拿多少还是看执行计划。
  • 选型含义：TempDB 要独盘、预分配、等大文件三件套写进部署规范；RCSI 不是免费午餐，POC 时必须开着目标隔离级别压测。

深水区四（运维与升级）：升级是单向门，真正的风险在优化器

  • 机制：in-place 升级不支持降级；备份只能向上还原；兼容级别让"引擎升级"与"优化器行为变更"解耦——老库升级后保留旧兼容级别，新 CE（基数估计器）只在新级别生效。
  • 推到边缘：
    • 升级最大的坑不是引擎装不上，而是升了兼容级别后执行计划回归：新 CE 对关联谓词、相关列的估计方式变了，慢查询在升级后"凭空"出现。标准流程是：保持旧兼容级别升级 → 开 Query Store 跑满一个业务周期采基线 → 逐库升兼容级别 → 用 Query Store 找回归强制旧计划。跳过基线直接升级别，等于闭眼换引擎。
    • 大表统计信息自动更新阈值约 SQRT(1000×行数)：10 亿行表要 100 万行变更才触发，统计信息"算新鲜"但实际已漂移很远——升级前后都要查统计信息新鲜度。
    • side-by-side 是生产环境唯一推荐路径（可回退=切 DNS），in-place 留给测试环境；50 个实例的 in-place 是单向门叠 buff。
  • 选型含义：升级预算要按"引擎升级 + 兼容级别爬坡 + 计划回归治理"三段算，只算第一段的一定爆。

深水区五（兼容与迁移）：Azure SQL 的"95% 兼容"是迁移时最贵的 5%

  • 机制：Azure SQL Database 与本地引擎同源但 PaaS 化：无 SQL Agent（用 Elastic Jobs/自动化）、无跨库查询（用 elastic query）、无手动备份（平台自动备份+PITR）、无 Windows 认证/链接服务器/FILESTREAM；Managed Instance 接近 99%，SQL VM 则是 100% 本地版。
  • 推到边缘：
    • 迁移评估（DMA/SSMA）扫出来"不支持"最多的三件套：SQL Agent 作业、跨库三段式命名、CLR/链接服务器——恰好是老系统最爱用的。
    • 计费模型 DTU（打包）vs vCore（分开配）：DTU 简单但扩缩不灵活，vCore 灵活但选错 tier 账单难看；Serverless 自动暂停省的是闲置钱，代价是唤醒延迟， latency 敏感的生产库别碰。
    • 备份策略要重写：本地那套"全备+差异+日志自建保留策略"在 SQL DB 上不存在，RPO/RTO 改由平台 SLA 定义，合规审计要换口径。
  • 选型含义：上 Azure 不是"搬机器"，是"换运维模型"；POC 必须跑真实作业与跨库调用，不要只测单库 CRUD。

客户经验

本区内容主要基于厂商口径与媒体转述，独立社区验证不足，引用时请打折。

生态 微软全家桶 —— AD 认证、BI 套件、.NET 的原生搭档

一句话
Windows 域/Entra ID 集成认证、SSIS/SSRS/SSAS、Power BI、EF Core——在微软技术栈企业里，SQL Server 不是"一个数据库"，是基础设施的一部分。
窄场景
.NET 技术栈企业、Windows 域环境、已有 Power BI/AD 投资的组织；"数据库要能被现有身份体系管起来"是硬需求。
机制
生态招牌的本质是"零摩擦"：AD/Entra 集成认证让数据库账号体系与公司身份体系统一（无额外密码管理）；SSIS（ETL）、SSRS（报表）、SSAS（多维分析）是买 license 附赠的 BI 套件；EF Core 是 .NET 的一等 ORM。单独看都不惊人，合在一起构成"微软店"的完整货架——竞争对手要一个个对打。
生产验证
Stack Overflow 全站跑在 SQL Server 上（Nick Craver 架构博客）："We're using SQL Server as our single source of truth."——顶级流量技术站点（.NET 栈）的生产背书（http://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/）。用户把它用成了"可靠的大铁块"，而不是微软包装的"智能平台"。诚实标注：中文社区一线证据弱（多为营销/教材类内容）。
竞品差距
PG/MySQL——无原生 AD 集成（要靠扩展/中间件），BI 套件要另购；Oracle——有生态但商业封闭且贵。".NET+Windows+AD"企业里，SQL Server 的生态位没有竞品——这不是性能比较，是"全家桶"比较。
证据等级
顶级流量站点生产背书（第三方工程师博客）+ 公认生态事实；中文社区一线证据弱（已标注）
最后核验
2026-10-01

内核 AlwaysOn 可用性组 —— "大铁块"的高可用

一句话
AlwaysOn Availability Groups 提供同步/异步提交、自动故障转移的成熟高可用，Stack Overflow 用它扛全站流量。
窄场景
需要"开箱即用"高可用的 OLTP：同步提交零数据丢失、自动故障转移、异地 DR 副本；团队不想自建 Patroni/Stolon 这类编排。
机制
AG 允许一个主副本 + 多个辅助副本（同步/异步），故障时自动转移，辅助副本可读（分担读流量）。对比开源方案：PG 的高可用要 Patroni/Stolon+etcd 自建，MySQL 要 MGR/InnoDB Cluster——SQL Server 把这套做进了产品内，SSMS 图形化可配。这是"大铁块"哲学：功能全、开箱即用、不折腾。
生产验证
Stack Overflow 架构：2 个 SQL Server 集群跑 AlwaysOn AG，每集群 1 主（NY）+ 异步副本（NY + Colorado DR）；硬件 Dell R720xd/R730xd（384–768GB 内存、PCIe SSD）——"scale up"到极致的单机+AG 架构，扛下全站流量（http://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/）。
竞品差距
PG——Patroni 可靠但要自建；MySQL——MGR 运维复杂度高于 AG；Aurora——故障转移更快但那是云托管。"自建/本地环境开箱即用的成熟 HA"，SQL Server 是省心之选——代价是授权费。
证据等级
顶级流量站点生产架构（第三方工程师博客，细节到硬件型号）
最后核验
2026-10-01

避坑 授权复杂度 —— 微软式"税"

一句话
按核数/版本（Standard vs Enterprise）的授权模型，高可用副本数、在线索引等功能按版本切分、价格差数倍——社区长期吐槽"为授权做架构"。
窄场景
预算敏感、想"按需用功能"的团队；被"Enterprise 版功能"勾引但付不起账单的中小企业。
机制
SQL Server 的经典槽点：可用性组副本数、分区表、在线索引重建等能力按版本（Standard/Enterprise）切分。架构决策经常变成"这个功能要 Enterprise，我们买得起吗"——技术选型被授权模型扭曲。这是买断制商业数据库的通病，但 SQL Server 因其中小企业用户基数大，吐槽声量最高。
生产验证
用户评价聚合站点的长期共识："High Licensing Costs""licensing complexity"常年出现在 SQL Server 的 cons 列表里（https://www.saasworthy.com/product/sql-server/reviews）。诚实标注：本次未留存具名单个生产账单故事——反向招牌证据弱。
竞品差距
PG/MySQL——开源无授权概念；Azure SQL——PaaS 化后按量付费，授权复杂度转移给云。这是"买断制商业数据库"的时代税，云托管版正在消解它。
证据等级
社区共识（用户评价聚合）；独立生产账单故事缺失（诚实标注）
最后核验
2026-10-01

用户最买账的 5 点

  1. SSMS + T-SQL 生态：RDBMS 里最成熟的工具链
    • 为什么是真的：SSMS 的图形化执行计划、活动监视器、Profiler/Extended Events 链条完整；T-SQL 人才池是所有数据库里最深的，招 DBA 最容易。
    • 边缘与限度：SSMS 是 Windows only，跨平台靠 Azure Data Studio（功能弱一档）；人才池深但老龄化，新生代开发者更熟悉 PG/MySQL。生态强的另一面是锁定——SSIS/SSRS/SSAS 全家桶迁出去的成本极高。
  2. 查询优化器与 IQP（智能查询处理）："不改代码变快"的代表
    • 为什么是真的：自适应连接、批处理模式、参数敏感计划优化（2022+）等多代 IQP 积累，优化器是业界标杆；很多升级收益不需要改 SQL。
    • 边缘与限度：优化器的聪明建立在统计信息和"第一次编译的参数值"上——参数嗅探（为首个参数值编译的计划被后续调用复用）是 DBA 的经典噩梦；2022 的参数敏感计划优化与 2025 的可选参数计划优化是缓解，不是根治。
  3. Always On 高可用口碑
    • 为什么是真的：同步提交 RPO=0 是真同步（备库日志落盘确认），可读副本能分流报表，2012 年至今 10+ 年生产验证。
    • 边缘与限度：见深水区二——同步的代价是提交延迟=网络 RTT，跨城同步 AG 的写延迟是物理定律；仲裁、redo 队列、人肉决策都是 RTO 的组成部分。"RPO=0"不等于"故障无感知"，应用重连与 DNS 切换的时间要算进去。
  4. 安全合规栈开箱即用
    • 为什么是真的：TDE、Always Encrypted、审计、RLS、动态掩码、Ledger 全是第一方功能，等保/金融合规要的材料一次配齐，不用攒第三方件。
    • 边缘与限度：见杀手特性 3——证书生命周期、审计存储、Ledger 写放大都是持续运维税；功能"有"不等于"开"，POC 时要按合规清单逐项验证开启状态与开销。
  5. 向后兼容：30 年前的应用还能跑
    • 为什么是真的：兼容级别机制让老库平滑升级；T-SQL 方言稳定，企业里跑 10 年以上的存储过程是常态。
    • 边缘与限度：兼容是双刃剑——老兼容级别意味着用老 CE、错过新优化器，"能跑"不等于"跑得好"；技术债被兼容性掩盖，越往后还越贵。选型时要问：团队是"需要兼容"还是"在拿兼容当借口不重构"。

吐槽清单

分类吐槽影响版本状态
授权坑按核计费随核数线性涨，Enterprise 成本在高核数下陡增；"小规模便宜、大规模贵"的模型随扩容反转全版本open
授权坑授权规则复杂：按虚机授权需 SA/订阅、被动副本免费有前提（SA 有效+真被动）、CAL 多路复用不省钱；SAM 审计是悬顶之剑全版本（2022 起按虚机授权规则收紧）open
授权坑Standard 与 Enterprise 功能刀法重：完整 AG、可读副本高级能力、部分安全/性能特性是 Enterprise 专属；买错版本=重构全版本open
性能坑参数嗅探：存储过程首次编译的参数值决定缓存计划，数据分布不均时后续调用性能断崖，"重启实例就好"是典型症状全版本partially-fixed（2022 参数敏感计划优化、2025 可选参数计划优化、Query Store 自动修正缓解）
性能坑锁升级：单语句超约 5000 锁触发行锁→表锁，批量 UPDATE 阻塞整表无关查询；NOLOCK 绕阻塞但可能丢行/重行全版本partially-fixed（2025 Optimized Locking 缓解争用，不改变升级阈值逻辑）
性能坑TempDB 分配页争用（PAGELATCH_EX）：高并发临时表/排序打满全局串行点；开了 RCSI 后版本存储再吃一波 TempDB全版本partially-fixed（2022+ tempdb 元数据优化与 GAM/SGAM 增强；文件数规范仍是必修）
性能坑大表统计信息自动更新阈值过高（约 SQRT(1000×行数)），10 亿行表可漂移百万行仍"算新鲜"，执行计划渐进式变坏全版本open
运维坑升级单向门：in-place 不支持降级，回退=备份还原到并行实例；备份不可向下还原全版本open（流程规避：side-by-side）
运维坑升兼容级别引发计划回归：新 CE 改变基数估计，老 SQL 在新级别下变慢；必须走"基线→升级别→Query Store 治理"三段式2014+（新 CE 引入后）open（流程规避）
运维坑AG 运维负担：WSFC/仲裁/Pacemaker（Linux）、redo 队列监控、同步延迟调优；"高可用"约等于"多雇半个 DBA"2012+open
运维坑MERGE 语句并发 bug 是社区共识坑：高并发下可能报错/错误结果，老手一律改写为 UPDATE+IF ROWCOUNT=0 INSERT全版本open
兼容坑Linux 版功能缺口：SSAS/SSRS/R 服务缺失、SSIS 在 2025 的 Linux 版不可用、容器不支持 Arc 相关能力、Intel 12 代+混合 CPU 在 Linux 上曾无法启动2017+partially-fixed（2025 补齐向量/JSON/Entra 等，但缺口仍在）
兼容坑Azure SQL Database "95% 兼容"：SQL Agent、跨库查询、CLR、手动备份等缺失，迁移时最后 5% 最贵全版本open
生态坑T-SQL/SSIS/SSRS 锁定：全家桶迁出成本极高，议价能力随使用深度递减全版本open
成本坑老版本钉子户：2008/2012 仍在生产环境跑，ESU（扩展安全更新）按年收费，升级拖延=持续交税2008–2014open

判决

  • 适合谁：Windows/.NET 技术栈团队；需要 RPO=0 同步高可用 + 可读副本分流的企业 OLTP；强合规行业（金融/政企/医疗）要开箱即用安全审计栈；已有 SQL Server DBA 人才储备、SSIS/SSAS/Power BI 全家桶的组织；"去 Oracle"但不想换分布式架构的传统企业。
  • 不适合谁：成本敏感的初创团队（授权是持续税）；Linux-first/云原生多语言团队（Linux 版是二等公民）；需要横向 scale-out 写扩展的互联网高并发场景；无专职 DBA 又想"装完不管"的团队（TempDB/AG/授权三件套都要人养）。
  • 迁移成本：MySQL → 中（方言差异大，SSMA 可评估，无协议兼容）；PostgreSQL → 中（SQL 方言接近但 T-SQL 特性、窗口函数细节、过程语言都要改）；Oracle → 中高（PL/SQL→T-SQL 改造成本高，但授权费从 Oracle 降到 SQL Server 是经典降本路径，SSMA for Oracle 可辅助）。

附录

询价前请先对齐以下每一项，否则报价单失真：

  1. 版本线：Enterprise（按核）还是 Standard（按核 / Server+CAL）——先定功能（AG 完整度、可读副本、安全特性），再定计费
  2. 核数口径：物理核还是 vCPU；虚机按虚机授权必须有 SA 或订阅；虚机 vCPU 是否虚胖（建虚机时随手给大是常见浪费）
  3. SA 状态：是否在有效期内——决定许可移动性、被动副本免费、版本升级权
  4. CAL 计数（如走 Server+CAL）：按用户还是按设备；经应用中间层不减少 CAL（多路复用规则）；互联网应用基本只能按核
  5. 高可用拓扑：被动副本是否"真被动"（可读=不免费）；仲裁见证的授权归属
  6. 非生产环境：开发/测试一律用免费 Developer 版，不要为非生产买 Enterprise
  7. 云路径：是否用 Azure Hybrid Benefit 折抵；Arc PAYG 按量是否比买断划算（波动型负载算三年 TCO）
  8. 历史包袱：老版本（2008–2014）是否在 ESU 续费，不如把 ESU 的钱折进升级预算

来源与待验证清单

  • 版本与发布：SQL Server 2025（17.x）GA 2025-11-18（Microsoft Ignite；TrustedTech/Neowin 报道）；Linux 版 CU6（17.0.4055.5）发布于 2026-06-17（Microsoft Learn 发版历史）；主流支持至 2031-01-07、扩展支持至 2036-01-07（第三方转述微软生命周期页）
  • 2025 新特性：原生 vector + DiskANN、原生 JSON 类型与 JSON 索引、正则函数、Optimized Locking（TID 锁/LAQ）、Entra 托管标识、Fabric 镜像、TLS 1.3/TDS 8.0（dev.to、The Register、TrustedTech；LAQ 是否需兼容级别 170 待验证）
  • 授权与版本：Enterprise 按核、Standard 按核或 Server+CAL、Standard 限 32 核/256GB（Microsoft Learn 2025 版本对照；licenseware.io、redresscompliance.com 授权指南）；Developer/Express 免费与限制（官方口径；Express 2025 库大小上限另有第三方称放宽，待验证）
  • Always On 机制：同步/异步提交、自动/手动/强制故障转移条件、2025 仲裁恢复增强（Microsoft Learn Always On 文档）
  • TempDB/锁/优化器：PAGELATCH 分配页争用与文件数规范、2022 tempdb 元数据优化（Microsoft Learn、bobsql 演示）；锁升级约 5000 阈值、参数嗅探、CE 统计阈值（社区 DBA 共识：erikdarlingdata、mssql-performance-skills）
  • 升级：单向门、备份不可向下还原、兼容级别解耦、Query Store 基线流程（社区 runbook：peterwhyte-lgtm；aws-samples 迁移参考；到 2025 的直升路径待以官方升级矩阵核对）
  • Linux/容器：不支持清单（Microsoft Learn 2025 Linux 版对照页）、容器不支持 Arc 相关能力、混合 CPU 启动问题、2025 Linux 版无 SSIS、SLES 在 2025 被移除
  • Azure SQL 差异：SQL DB ~95% / MI ~99% 兼容口径、无 SQL Agent/跨库查询/手动备份、DTU vs vCore（社区 skill 与 TechTarget 综述）
  • 下次评审：跟踪 SQL Server 2025 CU 更新中的 LAQ/参数计划优化细节，以及 Express 2025 限额是否有官方调整