简介

  本篇文章不仅仅是针对SQL Server 2025新推出功能的概览，而是从一个一线用户 / DBA 的视角出发，挑出我认为最值得关注的几个变化，有些功能会结合一些我的经验进行描述。

  本文主要聚焦于SQL Server 2025自身能力的变化，没有关注与Azure相关的能力。

  SQL Server 2025最大的变化，要我说，肯定是Logo:-)，按我的理解微软SQL Server不再是一个用来存数据的圆柱体，而是一个“AI-ready”的数据库了。

图：SQL Server 2025的新logo

  为了方便阅读，我将从以下几个方面展开讨论：

1. AI内置能力：从原生向量类型、DiskANN 向量索引，外部模型和服务集成功能，结合实际RAG架构示例来看SQL Server 2025如何把AI/向量检索/模型调用收拢到数据库内部。
2. 开发体验增强：原生二进制 JSON 类型与相关函数、聚合操作，以及基于 Google RE2 的正则表达式（Regex）支持，如何改进数据建模、清洗与日志解析体验。
3. 内核深度优化：锁机制（消除锁升级、LAQ）、参数化查询优化（如 OPTIMIZED_SP_EXECUTESQL、OPPO、CE Feedback）、列存改进以及 TempDB 相关增强。
4. 版本与规格演进：标准版资源上限的提升、Web 版下线，以及这些变化在阿里云 RDS for SQL Server规格矩阵和一键升级路径中的体现。
5. 运维与分析能力提升：备份压缩算法升级、备库备份支持、直接读取 OSS/S3上Parquet/文本数据等特性。

版本变化

  SQL Server 2025标准版资源上限再一次升级，由过去的24核128G升级到32核256G，但Web版就此下架。

  从阿里云 RDS for SQL Server的视角看，这次标准版上限提升到 32C/256G，会直接反映到产品规格矩阵中：RDS for SQL Server 2025 将不再提供 Web 版规格，而是以标准版 + 企业版的组合覆盖从轻量业务到核心生产负载。对于已经在用 RDS SQL Server 2016/2017/2019/2022 的客户，我们会提供一键平滑升级到 2025 的能力，避免自行重装、迁移、回滚预案等复杂操作，让版本升级更像是一次普通的变配操作。

AI内置能力

向量支持

简介

  向量是 AI 时代的基石。它可以为文本、图像、声音、视频等一切信息，标出一个“语义坐标”，简单来说，就是 AI 用来理解世界的语言。过去在业务系统中计算语义相关性，通常需要接入一套外部的专用向量数据库，这会带来很多挑战——数据要多存一份、链路要多走一跳、运维要多管一套，安全与一致性也要单独设计。计算机世界有句话：“+1 层可以解决所有问题”，但每多一层，架构、成本、延迟和故障面的复杂度，也都要一并算在内。

但如果将向量存储 + 近似最近邻搜索直接做到数据库引擎侧，是否就能减少这个加一层？

图：没有向量数据支持之前的应用程序

  该图中可以看到，做一个简单的RAG程序，需要从SQL Server中捞出数据，调用外部模型进行文本切块，向量嵌入，然后将数据再存储到外部的向量数据库中，例如Milvus

  整个程序的编排过程需要考虑数据同步、数据安全、数据一致性问题、同时还要考虑数据安全与隔离等问题。

图：有向量支持之后的SQL Server 2025

  而使用内置的向量类型+语义搜索，所有操作都可以集中在SQL Server中完成。

向量类型

  SQL Server 2025新增Vector数据类型VECTOR(n) ，VECTOR(n) 本质上是一个固定长度的浮点数数组，里面整整有 n 个元素。比如 VECTOR(3) 就是 3 维向量。示例数据：[0.1, 2, 30]，该数据类型在磁盘上以紧凑的二进制存储。避免了文本解析的 CPU 开销，同时能够大幅减少存储空间占用。

  现在我们可以使用下面SQL简单创建一个Vector类型的表并插入测试数据。

CREATE TABLE dbo.SampleVectors
(
    Id INT PRIMARY KEY,
    V  VECTOR(3) NOT NULL
);
GO
INSERT INTO dbo.SampleVectors (Id, V)
VALUES 
    (1, '[0.1, 2, 30]'),
    (2, '[-5.5, 0, 10.123]');

DiskANN

  向量索引算法通常是 HNSW（Hierarchical Navigable Small World）。它构建一个多层的图结构，导航速度极快。但HNSW 极其消耗内存。为了保证性能，它通常要求将整个向量图结构全部加载到 RAM 中，这意味着巨大的内存消耗。

  SQL Server 2025 采用了微软研究院发明的 DiskANN 算法。基本概念是DiskANN 将巨大的向量图结构存储在 SSD 上，在 RAM 中只保留极小的一部分“压缩向量”用于快速导航，查询时，算法通过优化的 I/O 访问模式，只需极少次数的磁盘读取即可找到目标。性能上尽管依赖磁盘，DiskANN 能够实现个位数毫秒级的延迟，虽然不如纯内存方案的性能，但硬件成本降低了 90% 以上 。

  在此值得一提的是阿里云RDS for SQL Server ESSD存储能够提供高达百万级的随机读写 IOPS 和微秒级延迟使得 DiskANN 能够快速遍历磁盘上的图结构，实现毫秒级向量搜索。

  DiskANN 算法本质上是用磁盘 IO 换内存空间。这意味着磁盘的随机读写性能直接决定了 AI 搜索的快慢。微软官方推荐 SSD，而阿里云 RDS 标配的 ESSD PL1/PL2/PL3 能提供百万级 IOPS 和微秒级延迟，这简直是为 DiskANN 量身定制的‘物理外挂’。在本地机房你可能需要昂贵的 NVMe 阵列，但在云上这只是配置单里的一个选项。

相似度函数

  微软针对向量类型，配套了下面 5 个函数，每个我都给一个最小 T-SQL 示例和一句话说明。

• VECTOR_DISTANCE ： 计算两个向量之间的“距离”

  VECTOR_DISTANCE('cosine', @a, @b) AS distance;

• VECTOR_NORM：计算一个向量的“长度 / 大小”（范数）

  VECTOR_NORM(@v, 'norm2') AS length;

• VECTOR_NORMALIZE：把向量“归一化”，调整成长度为 1 的向量。

  VECTOR_NORMALIZE(@v, 'norm2') AS normalized;

• VECTORPROPERTY：查询一个向量的属性，比如“多少维”、“底层数据类型”。

  VECTORPROPERTY(@v, 'Dimensions') AS dims,

• VECTOR_SEARCH：基于 DiskANN 向量索引，按相似度在大表里做近似最近邻搜索。

DECLARE @q VECTOR(3) = '[0.1, 0.2, 0.3]';
SELECT  s.Id,
        s.distance
FROM VECTOR_SEARCH(
        TABLE      = dbo.Products,
        COLUMN     = Embedding,
        SIMILAR_TO = @q,
        METRIC     = 'cosine',
        TOP_N      = 5
) AS s;

限制

  当前向量索引的限制非常多，最大的限制是表一旦启用向量索引后，就无法进行更新，据说未来该限制会移除。

  对于启用向量索引的表更新会产生如下报错：

Msg 42231, Level 16, State 1, Line 19
Data modification statement failed because table 'Articles' has a vector index on it.

DEMO

  下面demo用于创建一个带有向量数据类型的表，并创建索引后，进行余弦相似度查询

ALTER DATABASE SCOPED CONFIGURATION 
SET PREVIEW_FEATURES = ON;
GO
CREATE TABLE dbo.Articles
(
    ArticleID INT NOT NULL,               -- 必须是整数
    Title NVARCHAR(100),
    ContentCategory NVARCHAR(50),
    VectorEmbedding VECTOR(3),            -- 定义向量列，这里模拟3维向量
    
    -- 必须定义单个整数列的主键聚集索引
    CONSTRAINT PK_Articles PRIMARY KEY CLUSTERED (ArticleID)
);
INSERT INTO dbo.Articles (ArticleID, Title, ContentCategory, VectorEmbedding)
VALUES
(1, '量子物理基础', '科技', '[0.9, 0.1, 0.0]'),      -- 纯科技
(2, '宋代诗词赏析', '文学', '[0.0, 0.9, 0.2]'),      -- 纯文学
(3, '罗马帝国衰亡史', '历史', '[0.1, 0.2, 0.9]'),    -- 纯历史
(4, '科幻小说：火星救援', '混合', '[0.8, 0.7, 0.1]'), -- 科技+文学
(5, '工业革命史', '混合', '[0.7, 0.1, 0.6]'),        -- 科技+历史
(6, 'AI大模型原理解析', '科技', '[0.95, 0.05, 0.0]'); -- 强科技
GO
-- 4. 在 VectorEmbedding 列上创建向量索引
-- 注意：创建索引后，该表将变为只读（无法插入或更新数据），除非删除索引。
CREATE VECTOR INDEX idx_Articles_Embedding
ON dbo.Articles (VectorEmbedding)
WITH (
    METRIC = 'cosine',  -- 使用余弦相似度 (适合文本语义搜索)
    TYPE = 'DiskANN'    
);
GO
DECLARE @queryVector VECTOR(3) = '[0.9, 0.1, 0.1]'; -- 这是一个主要偏向科技的查询
SELECT 
    t.ArticleID,
    t.Title,
    t.ContentCategory,
    t.VectorEmbedding,
    s.distance -- 距离越小，相似度越高 (对于 Cosine 距离)
FROM 
    VECTOR_SEARCH(
        table = dbo.Articles AS t,
        column = VectorEmbedding,
        similar_to = @queryVector,
        metric = 'cosine',
        top_n = 3  -- 返回最相似的前3个
    ) AS s
ORDER BY 
    s.distance ASC;
GO

示例如下：

图：进行基于向量索引的相似度检索

通过HTTP调用外部服务

sp_invoke_external_rest_endpoint

  sp_invoke_external_rest_endpoint 允许 T-SQL 直接发起 HTTP 请求，也是其他函数下层的实现基础，那么数据库内的整体流程不再局限于引擎内部，可以大幅扩充引擎能力，例如结合我的经验，可能在下面一些场景可以使用。

可能的应用场景

1. AI 集成 (RAG): 这是目前最热门的用法。结合向量搜索，可以直接在 SQL 内部调用 AI 模型（如百炼或本地通义千问模型）来处理数据，完成 RAG流程。
2. 外部模型调用: 可以调用外部模型进行向量嵌入等。
3. 运维监控: 例如直接从 SQL Server 访问 Kubernetes API。
4. 函数计算集成: 可以调用阿里云函数计算完成复杂业务的外部函数集成。

例如调用百炼对文本进行embedding的示例如下：

DECLARE @Response NVARCHAR(MAX);
DECLARE @ApiKey NVARCHAR(100) = 'sk-xx'; 
DECLARE @AuthHeader NVARCHAR(MAX) = N'{"Authorization":"Bearer ' + @ApiKey + '"}';
EXEC sp_invoke_external_rest_endpoint
    @url = N'https://dashscope.aliyuncs.com/compatible-mode/v1/embeddings',
    @method = N'POST',
    
    @headers = @AuthHeader, 
    @payload = N'{
        "model": "text-embedding-v3",
        "input": "SQL Server 2025" 
    }', 
    @response = @Response OUTPUT;
SELECT @Response AS DirectApiResult;

图：调用外部模型服务

  另外我们注意到外部数据交换与模型数据交换基本上以JSON为主，文章后半部分提到对JSON的原生支持也能更方便地处理模型数据。

  同样，我们可以利用该函数直接触发阿里云函数计算 (FC)。例如，当数据库插入一条新订单时，直接通过 T-SQL 调用 FC 发送钉钉通知或触发复杂的业务逻辑，实现真正的“数据库驱动的Serverless架构”

  例如我们可以发送钉钉通知：

DECLARE @Response NVARCHAR(MAX);
DECLARE @Url      NVARCHAR(4000);
DECLARE @Body     NVARCHAR(MAX);
SET @Url = N'https://oapi.dingtalk.com/robot/send?access_token=xxx';
SET @Body = N'{
  "msgtype": "text",
  "text": {
    "content": "SQL Server 任务已完成（来自 SQL Server）"
  }
}';
EXEC sp_invoke_external_rest_endpoint
    @url      = @Url,
    @method   = N'POST',
    @payload  = @Body,
    @response = @Response OUTPUT;
SELECT @Response AS DingTalkResult;

图：通过T-SQL发送钉钉通知

图：钉钉中收到消息

CREATE EXTERNAL MODEL

  SQL Server 2025 引入了 CREATE EXTERNAL MODEL 语句，用于简化对于Text Embedding 模型的调用，该语句用于注册AI模型的元数据，下层依然依赖sp_invoke_external_rest_endpoint 存储过程。

  但该功能在国内相对受限，该函数会强制检查api.openai.com域名，只有该域名才能够发送Authorization这个HTTP头，因此与国内的很多第三方模型并不兼容，第三方的使用方式依然需要依赖sp_invoke_external_rest_endpoint进行更low level的调用。

  实际使用时，先定义模型，如下：

sp_configure 'external rest endpoint enabled', 1;
RECONFIGURE;
GO
CREATE DATABASE SCOPED CREDENTIAL [OpenAI_Cred]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE', 
     SECRET = 'sk-Proj-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'; 
GO
CREATE EXTERNAL MODEL [OpenAI_Embedding_Model]
WITH (
    LOCATION = 'https://api.openai.com/v1/embeddings',
    API_FORMAT = 'OpenAI',
    MODEL_TYPE = EMBEDDINGS,
    MODEL = 'text-embedding-3-small', 
    CREDENTIAL = [OpenAI_Cred]
);
GO

典型的使用主要是两个函数：

• AI_GENERATE_CHUNKS： 用于将长文本切片
• AI_GENERATE_EMBEDDINGS： 用于将文本向量化

一个典型的场景例如将长文本先切片，然后向量化：

SELECT 
    d.DocID,                                -- 保留原文档ID
    c.chunk_id,                             -- 切片生成的序号（第几块）
    c.chunk AS ChunkText,                   -- 切出来的那一段文本
    -- 第二步：直接将切好的文本喂给 AI 生成向量
    AI_GENERATE_EMBEDDINGS(c.chunk USE MODEL MyOpenAI) AS VectorData
FROM 
    dbo.ProductDocs AS d                    -- 源表（长文本）
    -- 对每一行数据执行一次长文本切片
    CROSS APPLY AI_GENERATE_CHUNKS(
        SOURCE = d.LongDescription,         
        CHUNK_TYPE = FIXED,                 -- 切分方式：固定长度
        CHUNK_SIZE = 500,                   -- 每块大小：500字符
        OVERLAP = 50                        -- 重叠部分：50字符（防止切断上下文）
    ) AS c;

新SQL Server 2025 AI能力在RDS上的应用

  对于阿里云 RDS 来说，一个非常直接的落地方式是：把 SQL Server 2025 当作“业务库 + 向量库”的统一承载层，底层配 ESSD PL1/PL2 乃至 PL3 盘型，利用高 IOPS 和低延迟支撑 DiskANN 的随机访问；在同一专有网络内，通过函数计算（FC）或 API 网关对接百炼上的通义大模型，将切片、Embedding、RAG 推理全部收束在一条内网链路中。相比“业务库 + 外挂向量库 + 外网模型服务”的三层架构，这种“RDS 向量库 + 内网大模型”的组合可以明显降低运维复杂度和链路风险。

一个可能的架构如下图所示：

变更事件流（Change Event Streaming，CES）

  说到CES不得不提一下CDC，CDC属于一个业界标准的变更捕获工具，由SQL Server 2008开始引入，对于该功能，我有点一言难尽，该功能的本质并不是集成在内核中，而是依赖一系列系统存储过程，系统表以及SQL Server Agent作业 的 LogReader 作业读取事务日志完成，复杂度和IO负载开销非常高，我做过这么多年SQL Server依然不敢保证能解决所有的CDC相关问题。

  而CES工作原理是不再把变更数据写回本地数据库，而是直接从内存或日志中截获变更，打包成标准事件，推送到外部。带来的好处是不需要在数据库内维护巨大的系统变更表，大幅减少 I/O。下游消费者（如实时数仓、微服务）直接订阅消息队列，完全不需要触碰生产数据库。同时获取近乎实时的数据流传输。

  虽然 CES 在协议层面上宣称支持 AMQP 和 Kafka 协议，但在 SQL Server 2025 的当前预览版和微软的官方支持路径中，它主要且唯一支持的目标端点是 Azure Event Hubs (Azure 事件中心)。

  在国内公有云场景下，当前更成熟、可落地的路径依然是“SQL Server CDC + 阿里云 DTS/消息队列”的组合：由数据库负责变更捕获，由 DTS 或自建消费程序转发到 Kafka、数据湖或实时数仓。未来如果 CES 对第三方云平台开放Endpoint，我们也会评估如何在 RDS 中提供托管级的一键配置能力。

图：CES与传统CDC的对比

TempDB增强

避免单个查询打满tempdb

  TempDB 是所有会话共享的公共资源。如果某个用户的烂查询（比如发生了巨大的 Hash Spill 或笛卡尔积）把 TempDB 撑爆了，其他所有正常的业务（哪怕是极其简单的 SELECT）都会因为无法分配临时空间而产生整体的故障。

  SQL Server 2025利用 Resource Governor (资源调控器)，你可以给不同的 工作负载组 (Workload Group) 设定 TempDB 的使用上限。一旦某个组的查询试图使用超过配额的 TempDB 空间，SQL Server 会直接终止 (Kill) 该查询并报错（错误代码 1138），从而保护 TempDB 剩余空间。

  在我看来该功能稍显鸡肋，今天流行的趋势是去DBA化以及数据库的微服务化（过去更喜欢一个实例承载所有负载，今天更可能是单个实例承载特定负载，从而每个实例变小），需要DBA进行这么专业细粒度的配置有点强人所难，但对云原生环境下的多租户隔离或防范 "烂 SQL"炸库有奇效”，多了一种处理手段。

TempDB支持快速恢复

  TempDB支持ADR，针对一些TempDB 中存在未提交的大事务（例如复杂的临时表操作），崩溃后也能快速恢复，避免长时间的TempDB恢复过程。该问题在我的职业生涯中还真遇到过，不过的确是一个增强，启用方式如下面脚本

ALTER DATABASE TempDB SET ACCELERATED_DATABASE_RECOVERY = ON;
GO

开发体验增强

JSON支持

  SQL Server 2025增加了原生的JSON属性类型，而不是过去对JSON的支持那样，仅存储JSON文本数据。并与新的数据类型匹配一些额外的JSON函数，详情见链接。

  以前的JSON下层存储还是nvarchar，问题比较多，主要是存储空间，验证，性能问题。有了原生JSON类型可以非常高性能处理该类问题，可以通过下面DEMO简单试验新的JSON类型。

USE master;
GO
IF EXISTS (SELECT * FROM sys.databases WHERE name = 'JsonDemoDB')
    DROP DATABASE JsonDemoDB;
GO
CREATE DATABASE JsonDemoDB;
GO
USE JsonDemoDB;
GO
-- 确保兼容性级别为 170 (SQL Server 2025)
ALTER DATABASE JsonDemoDB SET COMPATIBILITY_LEVEL = 170;
GO
CREATE TABLE Orders (
    OrderID INT IDENTITY(1,1) PRIMARY KEY,
    -- 注意：这里直接使用了 JSON 类型，而非 NVARCHAR(MAX)
    OrderInfo JSON NOT NULL 
);
GO
-- 插入测试数据
INSERT INTO Orders (OrderInfo)
VALUES 
    ('{"Customer": "Alice", "Amount": 100, "Items": ["Book", "Pen"], "Tags": ["Urgent", "Office"]}'),
    ('{"Customer": "Bob",   "Amount": 250, "Items": ["Keyboard"],    "Tags": ["Electronics"]}'),
    ('{"Customer": "Charlie","Amount": 50, "Items": ["Soap"],        "Tags": ["Home", "Sale"]}'),
    ('{"Customer": "Dave",  "Amount": 1000,"Items": ["Laptop"],      "Tags": ["Electronics", "Urgent"]}');
GO
-------------------------------------------------------
-- 2. 新的聚合函数 (JSON_ARRAYAGG & JSON_OBJECTAGG)
-------------------------------------------------------
-- 场景 A: 将所有订单详情聚合成一个巨大的 JSON 数组
-- 以前需要用 FOR JSON PATH 拼接，现在更直观
SELECT JSON_ARRAYAGG(OrderInfo) AS AllOrdersArray
FROM Orders;
GO
-- 场景 B: 生成 Key-Value 对象
-- 将 OrderID 作为 Key，OrderInfo 作为 Value
SELECT JSON_OBJECTAGG(OrderID : OrderInfo) AS OrdersMap
FROM Orders;
GO
-------------------------------------------------------
-- 3. 原地数据修改 (.modify 方法)
-------------------------------------------------------
SELECT OrderID, OrderInfo 
FROM Orders 
WHERE OrderID = 2;
-- 以前：需要取出字符串 -> JSON_MODIFY -> 存回整个字符串
-- 现在：直接在列上调用 .modify 方法，性能更高，日志更优
UPDATE Orders
SET OrderInfo.modify('$.Amount', 300) 
WHERE OrderID = 2;
GO
-- 验证更新结果
SELECT OrderID, JSON_VALUE(OrderInfo, '$.Amount') AS NewAmount
FROM Orders 
WHERE OrderID = 2;
GO
-------------------------------------------------------
-- 4. JSON 索引与 JSON_CONTAINS
-------------------------------------------------------
-- 查询：查找 Tags 中包含 "Electronics" 的订单
-- 此时没有索引，将执行全表扫描 (Scan)
SELECT OrderID, JSON_VALUE(OrderInfo, '$.Customer') AS Customer
FROM Orders
WHERE JSON_CONTAINS(OrderInfo, 'Electronics', '$.Tags[*]') = 1;
GO
-- 创建 JSON 索引
CREATE JSON INDEX idx_json_orders ON Orders(OrderInfo) FOR ('$');
GO
-- 再次执行相同的查询
-- 此时优化器应选择使用 JSON 索引，极大提升大数据量下的性能
SELECT OrderID, JSON_VALUE(OrderInfo, '$.Customer') AS Customer
FROM Orders
WHERE JSON_CONTAINS(OrderInfo, 'Electronics', '$.Tags[*]') = 1;
GO
SET STATISTICS IO OFF;

在我看来，原生二进制存储和原地更新彻底解决了以往 JSON 在关系型数据库中空间膨胀和修改低效的两个痛点。这有点相当于在 SQL Server 内部内嵌了一个小型的高效的 NoSQL 数据库，按我的理解由于JSON空间占用下降50%左右，而对于JSON的修改不再需要将整个JSON读出再写回数据库，而是仅更新二进制字段中的一小部分。对于一些遥测、游戏等业务场景会极大提升性能，同时也能更好地支持 AI 相关数据的处理。

正则表达式支持

  过去 SQL Server 没有原生正则表达式支持，大家要么用很弱的like操作，要么使用 CLR / 外部服务，部署和调试都较为麻烦，SQL Server 2025引入了基于 Google RE2 库的原生正则表达式函数支持。主要是下面这几个：

• REGEXP_LIKE (string, pattern, flags)：用于 WHERE 子句。例如，验证邮箱格式或查找特定模式的产品序列号。

  -- 构造一组邮箱字符串（不依赖任何真实表）
  SELECT v.Email
  FROM (VALUES
      ('user@example.com'),
      ('not-an-email'),
      ('admin@test.org')
  ) AS v(Email)
  WHERE REGEXP_LIKE(
            v.Email,
            '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$'
        );
  -- 结果
  user@example.com
  admin@test.org

   

• REGEXP_REPLACE (string, pattern, replacement,...)：用于正则替换。例如，将电话号码格式统一化，或去除敏感信息。

  -- 去掉非数字字符，比如电话里混着空格、括号、横线
  SELECT REGEXP_REPLACE('(010) 1234-5678', '\D', '') AS PhoneDigits;
  -- 结果
  01012345678

   

• REGEXP_SUBSTR 和 REGEXP_INSTR：用于提取和定位。

  -- 从文本中提取形如 ERROR:后面跟三位数字的错误码
  SELECT REGEXP_SUBSTR('something wrong, ERROR:500 occurred',
                       'ERROR:\d{3}') AS ErrorCode;
  -- 结果
  ERROR:500

   

• REGEXP_SPLIT_TO_TABLE：这是一个强大的表值函数，它可以根据正则模式将字符串拆分为多行。这在处理非结构化日志数据或 CSV 格式数据时较为高效。

-- 按逗号、分号或竖线任意一个或多个拆分
SELECT value, ordinal
FROM REGEXP_SPLIT_TO_TABLE('WARN:disk|ERROR:io;INFO:done',
                            '[,;|]+');
-- 结果
value      ordinal
---------- -------
WARN:disk  1
ERROR:io   2
INFO:done  3

  在我看来这次的更新主要是补齐历史欠账：和 Oracle / PG / MySQL 对齐，这几个引擎已经更早支持了正则表达式相关函数，这次SQL Server属于补课，而从函数的使用体验上看，更像是优先服务数据清洗、日志分析、AI 前处理等场景，而不是 OLTP 的日常使用。

备份增强

备份压缩算法升级

  备份可以选择使用新的压缩算法，根据微软的说法压缩率有提升，备份过程中的CPU占用下降，吞吐率提升，算法来自：https://github.com/facebook/zstd

  可以使用下述SQL指定新的压缩算法进行备份。

BACKUP DATABASE AdventureWorks TO DISK = 'c:\temp\adw.bak' WITH COMPRESSION
(ALGORITHM = ZSTD, LEVEL = LOW), INIT, FORMAT

  后续阿里云RDS for SQL Server 2025也会将该备份算法作为默认备份算法。除了减少常规备份空间使用外，同时也会降低RDS冷存、异地灾备的备份空间占用。

备库备份

  备份方面，SQL Server 2025 现在支持在任意辅助节点上执行完整和差异备份（此前只能做copy-only备份）。这意味着主库压力可进一步减轻，备库可以定期承担备份任务而不影响主库事务处理

  在阿里云RDS for SQL Server的控制台上，对于企业集群版实例，可以做到备库备份，未来我们也会针对SQL Server 2025推出全量备份与差异备份的能力，进一步释放备库的资源。

图：阿里云RDS for SQL Server集群版支持备库备份

  这里值得一提的是很多使用阿里云RDS SQL Server集群版的客户，AlwaysOn备库不仅用于作为HA的备节点，同时只读实例还可以分担报表和分析负载。在过去，由于统计信息更新不及时，主库和只读库的查询性能可能差异巨大。SQL Server 2025 默认在辅助副本上启用 Query Store。主库的统计信息会更智能地同步给只读库，同时只读库的运行时统计信息也会回传。这会更大可能减少主库和备库同SQL的性能表现差异。

引擎内核优化

锁优化

  SQL Server 2019开始引入ADR，2022开始较为成熟，ADR对于极大降低停机时间非常重要（我之前的文章提到过，我曾经处理一个客户问题，用户有一个8个小时长事务没提交，重启sql server后停机接近一夜做undo/redo recovery，而启用ADR后该时间可以降低到5分钟内），基于该技术，锁机制也大幅升级（数据库需要开启ADR），主要体现在下面两个点

消除锁升级 (XACT Locks)

  比如一次我们更新1万行数据，表整体可能存在1亿行数据，那么行锁可能升级为表锁，虽然锁的开销减少，但表锁极大增加阻塞范围，我们可以看到一些典型业务比如归档历史数据，或者一些业务按字段更新某一列，如果该查询非常频繁，其他正常的select受到影响，那么该过程带来的阻塞会明显拖慢系统，消除锁升级理论上可以明显增加系统的吞吐量。

  整个原理是当事务修改行时，它仍然会短暂获取页面和行锁来执行修改，但在修改完成后立即释放这些底层锁。事务不再持有成千上万个行锁，而是仅持有一个 TID 锁（即 XACT Lock）。因为 ADR 已经标记了哪些行版本属于这个 TID，数据库只需要锁定这个 TID。任何其他查询如果试图访问这些行，会看到它们属于一个活跃的 TID，从而通过检查 TID 的状态来判断是否被阻塞。因此无论你更新 10,000 行还是 100 万行，系统只维护极少量的 XACT 锁。不再触发锁升级，表锁不会发生，从而极大提升并发性。

资格确认后加锁 (Lock After Qualification - LAQ)

  这是优化锁定解决“扫描期间”不必要阻塞的方式。这需要结合 READ_COMMITTED_SNAPSHOT (RCSI) 隔离级别使用。

传统锁方案：先加锁再检查

  在默认的 READ_COMMITTED 隔离级别下，SQL Server 在扫描数据以寻找符合更新条件的行时，通常会采用悲观策略：

  例如我们update某个字段，会扫描多行，每次扫描都需要查看是否满足Where条件如果不符合，释放锁；如果符合，保持锁并更新。 即使是不符合条件的行，在扫描经过时也会被短暂加锁，可能导致阻塞其他事务。

优化锁方案：LAQ

  LAQ 实现了“免锁谓词评估”，整体思路是它利用空间（tempdb 版本存储）换取时间（更高的并发度）。

  SQL Server 在不获取更新锁（U锁）的情况下扫描行，只有当确定某一行满足更新条件后，引擎才会去获取必要的锁（XACT 锁）保护修改。查询在寻找数据的过程中不会干扰其他事务，只有真正要修改的那一瞬间才会产生阻塞。

  通常是在UPDATE ... WHERE ... 语句有很好的优化效果，比如高并发的update语句，虽然修改的是不同行，但互相阻塞导致卡慢，关于这里我做DBA时有一些经验，处理方式比如

• 分批查询，一次更新1000行，拆分成循环一次更新100行
• 强制加锁提示（锁成本vs阻塞成本的trade-off）
• 禁用锁升级
• 表分区（锁整表变为锁分区）

  无论哪种方式都需要有成本和trade-off，且需要有一定的dba水平，这类内核级优化会让很多传统的 DBA 经验逐渐失效。

参数化查询

  sp_executesql 用于支持“即席查询”（Ad Hoc Queries）的参数化， 是写T-SQL使用较多的脚本，主要收益主要来自于下面两点

• 减少编译开销：如果两个查询只是 WHERE 子句中的值不同（例如 ID=1 和 ID=2），参数化可以让它们共用同一个“执行计划”，避免 CPU 浪费在重复编译上。
• 安全性：防止 SQL 注入攻击。

  很多SQL Server的驱动（例如ADO.NET, JDBC等）使用了参数化查询之后底层驱动会自动将其转换为 sp_executesql 发送给SQL Server。

  之前版本遇到的一个问题是大量并发同时进来执行sp_executesql时，会重复多次编译，引起所谓的“编译风暴”，会瞬时体现在高CPU上，在阿里云RDS控制台可以看到相关指标，如果有 100 个并发请求，且缓存中没有计划，会 100 次编译，生成 100 个重复的执行计划。

图：阿里云RDS for SQL Server控制台关于编译的性能指标

  而通过下面命令，可以允许加编译锁，只编译一次

USE [YourDatabaseName];
GO
-- 开启优化选项，强制 sp_executesql 获取编译锁
ALTER DATABASE CURRENT
SET OPTIMIZED_SP_EXECUTESQL = ON;
GO

  未来在阿里云控制台与API上，我们也会针对SQL Server 2025增加对该选项的支持。

图：阿里云RDS SQL Server对于数据库级别的属性管理

  等等，那遇到“参数敏感性”的SQL怎么办? 还记得SQL Server 2022支持的PSPO (Parameter Sensitive Plan Optimization) 吗，针对同一个SQL缓存多份执行计划，当出现一部分SQL成本大幅提高后，通过QueryStore动态匹配最佳计划从而避免所谓的“参数嗅探”问题，可以搭配使用，该部分不再展开，简单总结一句话是通过SQL Server 2025 通过 OPTIMIZED_SP_EXECUTESQL 在高并发下编译得更稳，同时利用PSPO 在不同参数下控制可能的性能衰退。

可选参数计划优化 (Optional Parameter Plan Optimization, OPPO)

  根据微软文档（链接）相比之前提到的PSPO解决数据倾斜导致的参数嗅探问题，OPPO解决的是参数忽有忽无的问题，例如这样一个条件WHERE (ID = @p OR @p IS NULL)， 优化器必须为参数P为null时进行兜底，而这种兜底通常落在执行计划上就是一个SCAN，即使参数p有一个高选择性的值也是如此，现在通过OPPO，为这两种情况生成不同的执行计划，避免这种参数时有时无时的性能巨大反差。

这是一个典型的为类似“上帝存储过程”兜底的机制，我曾经见过一个两千行的存储过程（执行计划20MB），已经是一个庞然大物，存在大量的可选参数，无人敢动，按照OPPO机制，如果平移到2025，应该会有不错的性能提升。

新的CE feedback for expressions

SQL Server从7.0 到2014之前（兼容级别低于2014）评估是基于这样一个假设，数据之间没有关联，例如where a =1 and b=2 的预估行数= a的选择性*b的选择性*总行数。

  SQL Server 2014以上（兼容级别>=2014）的预设的场景是数据有较多关联，而同一个表多个条件之间预估行数应该更多。

  这两者之间适应不同负载类型，旧模型更适合关联度低简单的负载类型，新模型适合关联度较高更复杂的查询（微软称之为“modern workload”）

SQL Server 2022针对单SQL语句基于反馈自动决定使用哪种评估，到了SQL Server 2025，可以针对SQL中的部分逻辑进行评估，而这部分语句可以在不同的SQL中复用。

SQL Server 中使用Query Hash识别“这是否是同一个查询”。现在，它引入了更细粒度的表达式指纹。比如下面查询：INNER JOIN Orders AS O ON C.custkey = O.o_custkey WHERE O.o_totalprice > 10000

无论这个逻辑片段是出现在一个简单的 SELECT * 中，还是嵌在一个极其复杂的 500 行报表 SQL 中，只要这个片段的指纹一致，系统就认为它们是“同一类问题”。

当系统发现某个指纹的基数估算持续错误（例如总是低估关联后的行数），它会尝试应用不同的模型假设 (Model Assumptions)，这通常表现为自动添加 Hint：

• ASSUME_MIN_SELECTIVITY...：假设过滤条件的选择性最小。
• ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS...：假设连接条件依赖于过滤条件（修正相关性假设）。
• Containment / Independence：修正列与列之间是独立分布还是包含关系的假设。

从理论来看，该功能是一个大杀器级别的，除了可复用的片段部分，可以很好地提升现有复杂查询的执行计划质量，例如：

SELECT * FROM Orders 
WHERE Status = 'Shipped' 
  AND ShippedDate IS NOT NULL;

  下面where条件中，两个条件是有相关性的，订单已发货，那发货日期一定不为NULL，但SQL Server对此不知道，可能导致估计行数严格偏低，可能导致授予内存过少产生“spill to tempdb”，通过CE子片段 Feedback， 针对这两个条件Status = 'Shipped' AND ShippedDate IS NOT NULL; 这个代码片段进行指纹级缓存，知道具有关联性，从而修正基数估计（预估行数增加），产生更好的执行计划。

启用的方式是将兼容级别调整到160（也就是SQL Server 2022的兼容级别）。

ABORT_QUERY_EXECUTION提示

  ABORT_QUERY_EXECUTION 当某个查询负载很高，但并不关键时，过去针对这类查询我们只能修改应用解决，但这个工作由于涉及应用发布通常短期无法快速完成，当需要进行所谓的紧急止血时，可以在Query Store中找到该查询的query id，从sql server层面对该语句打标，从而禁止执行。

打标后应用侧会收到如下报错：

Msg 8778, Level 16, State 1
Query execution has been aborted because the ABORT_QUERY_EXECUTION hint was specified.

   比如一个典型的场景，过去系统一个离职的开发人员遗留了一个每小时的定时巡检任务，短期我们发现该查询业务价值很低，同时相关收件邮箱已经失效，账号使用的是统一账号不能直接封禁账号，又影响sql server性能，可以利用该功能直接对相关SQL贴封条。

  我个人对此的评价来说聊胜于无，SQL Server过去也有引擎侧做一些动作的功能叫Plan Guide，由于该功能复杂性与使用门槛太高，罕有使用，ABORT_QUERY_EXECUTION或许也会如此。

列存提升

  SQL Server的列存在我看来是一直被低估的能力，以我个人经验，列存有极好的压缩比以及极致的分析性能，在数据归档、分析、HTAP场景中都有不错的表现，但很少见到客户使用该功能，有点扯远了...

  在 SQL Server 2022 中，微软引入了“有序聚集列存索引 (Ordered CCI)”，这让数据在存储时按特定列排序，极大地提升了段消除 (Segment Elimination) 的能力（例如where a>100 and a<500 则不会扫描a>500 的数据分段，极大提升分析类查询的性能）。

  SQL Server 2025将该功能下放到非聚集列存索引 (NCCI)。比如核心表是一个B-Tree行存表，但同时挂了一个 NCCI 用于报表分析。现在该 NCCI 也可以做到有序。

  同时对于有序NCCI的创建和Rebuild也支持Online了，也就是不锁表重建，我理解该能力主要是针对HTAP场景，避免只读分析负载过多影响OLTP。

读取 Parquet 或 text 格式不再依赖 PolyBase

不再需要预安装就可以直接支持读取S3兼容的Apache Parquet 格式，比如阿里云OSS的文件可以直接这样读取（前置需要配置OSS的AK），该功能在以下场景中会比较有价值：

• 冷热数据分离
• Zero ETL
• 临时外部数据源分析

In-Memory OLTP支持移除内存优化表相关对象

该部分主要是允许删除内存优化表、文件、文件组。是一个小提升，这里我专门提一下是因为之前发现错误地启用内存优化文件组后，客户无法删除，导致需要重新将数据库的数据导出导入，非常的繁琐，现在可以直接移除进一步增加了可运维性。

​转自https://www.cnblogs.com/CareySon/p/19302121/