SQL Server 2025 预览版新功能点评

T-SQL 语言增强

正则表达式 (Regex) 支持

• 功能概述： SQL Server 2025 在 T-SQL 中原生引入了 POSIX 兼容的正则表达式支持，通过内置函数（如 REGEXP_LIKE、REGEXP_REPLACE 等）可直接在查询中对文本进行复杂模式匹配、查找和替换。这让开发者可以在数据库层面使用正则表达式，无需外部代码或 CLR 扩展。
• 优势与预期用途： 正则表达式功能非常灵活，适用于复杂的字符串处理场景，如验证格式、提取信息、批量替换、数据清洗等。它消除了以前需要多步操作或外部程序才能完成的字符串操作。例如，可以在一个 SQL 查询中完成对复杂格式数据的验证和提取，简化了代码并提高了可读性。
• 批评与局限性： 社区反馈该功能目前对执行计划的影响较大，尤其在大表上性能不佳。优化器倾向于进行全表扫描，而不会利用索引，如 Brent Ozar 测试中所示，对 1GB 表进行正则查询时，SQL Server 未使用索引而全表扫描，导致耗费大量 I/O 和 CPU。其代价模型也很保守，会错误地将匹配行数估计为表总行数的 30%，导致查询计划极度低效（例如测试中正则查询耗费 60 秒 CPU 时间）。因此，正则功能目前适合少量数据或离线工具使用，不建议直接用于对 OLTP 级大表生产环境的查询；对于简单模式匹配，反而可使用 LIKE 等传统方式。
• 评价与建议： 正则功能极大地扩展了 T-SQL 的表达能力，但目前版本下需谨慎使用。在设计查询时应注意优化器行为：尽量限制数据量后再用正则，或者配合索引提示；必要时可预先筛选，再用正则匹配。对于常见模式匹配需求，可优先考虑 LIKE 或全文索引等传统方案。随着后续迭代完善，这一功能可在特定场景（如数据清洗、日志分析、复杂验证）下优先采用，但在关键业务 OLTP 查询中应先评估性能。

模糊字符串匹配 (Fuzzy Match)

• 功能概述： 新增了一组模糊匹配函数，包括 EDIT_DISTANCE、EDIT_DISTANCE_SIMILARITY、JARO_WINKLER_DISTANCE、JARO_WINKLER_SIMILARITY 等。这些函数用于计算两个字符串间的相似度或编辑距离，帮助开发者在 T-SQL 内进行近似匹配。
• 优势与预期用途： 模糊匹配可应对数据中拼写错误、同音异形、大小写差异等问题，提高数据匹配的灵活性和准确性。例如，在对客户名、地址、产品名等做去重、清洗或关联时，这些函数能识别“Johnathan”与“Jonathon”这样的变体，大幅减少人工干预。它们简化了过去需要自行实现算法或借助外部程序才能完成的任务，是数据质量和实体解析场景的利器。
• 批评与局限性： 目前这些函数还处于预览阶段，存在一些限制。其比较并不遵循列排序规则（Collation），即大小写、重音等规则暂不生效；未来版本会增加对排序规则的支持。此外，模糊计算本身复杂度较高，在海量数据上执行可能开销不小，需要与恰当的索引或筛选条件配合使用。社区尚未给出大量实战反馈，但应注意这些函数在大表上可能性能偏低，需要进行测试和优化。
• 评价与建议： 模糊匹配极具实用价值，特别适合数据清理、实体识别等工作。建议在需要精准匹配之外灵活匹配时使用，如数据去重、拼写校正等场景。由于目前实现还在完善中，应在重要项目中谨慎使用，并持续关注后续性能改进更新。对于性能敏感的场景，可先在小数据集上验证效果，再逐步推广；对于简单模糊匹配，可结合字符串函数和索引进行优化。

DATEADD 支持 BIGINT

• 功能概述： DATEADD 函数现在支持将增量参数（number）指定为 BIGINT 类型。这意味着在对日期/时间进行大跨度或微秒级的增量运算时，不再受 INT 范围限制。
• 优势与预期用途： 支持 BIGINT 后，可实现更精确和更大范围的时间计算，例如对 NANOSECOND、MICROSECOND 级别的增量运算，以及计算跨越极长时间跨度的时间差值。对于需要历史数据回溯、未来时间点计算或精细化时间窗口分析的场景，这提供了直接支持。
• 批评与局限性： 该增强功能主要是扩展类型支持，本身无明显缺陷；唯一需注意的是，实际存储的时间数据类型（如 DATETIME2）仍有最小和最大值范围，所以输入超出可表示范围时会报错。此外，对非常大的增量计算可能引入整型运算的性能开销，但通常影响不大。
• 评价与建议： 这一改进使时间运算更灵活可靠。建议在需要高精度或大跨度时间计算时使用，大大简化了此前需要分段计算或复杂逻辑才能实现的用例。总体而言，这是一个对数据仓库和时间序列处理很有用的功能，可放心在新系统中优先采用。

sp_executesql 优化

• 功能概述： 为减少编译风暴（大量查询同时编译导致资源争用），新增了“优化的 sp_executesql”模式。启用后，sp_executesql 的执行将类似于存储过程，从而串行化编译过程、降低并发编译开销。
• 优势与预期用途： 在高并发环境下，大量临时或动态 SQL 调用会触发重复编译。此功能通过将 sp_executesql 的编译序列化，可显著降低并发编译压力，从而提升整体吞吐。对于使用动态 SQL 较多的应用（如 ORM、报表系统），能缓解性能瓶颈。
• 批评与局限性： 该功能需显式开启，不默认启用。部分用户可能忽略，需在测试后决定是否激活。启用后，编译确实串行化，但对于某些场景可能略微增加单个查询的延迟。总的来说，社区暂未报告严重缺陷，但需注意对比和监控编译时间。
• 评价与建议： 如果遇到编译资源争用问题，此功能非常有价值。建议在出现性能瓶颈时测试开启，并衡量其对系统的实际效果。对于大多数应用，在确认可用且稳定后可以优先使用，以提升并发执行的可靠性；但若系统并发编译本来就少，可根据实际情况选择。

JSON 支持增强

原生 JSON 数据类型

• 功能概述： SQL Server 2025 引入了原生 JSON 数据类型（ANSI SQL 标准），以二进制格式存储 JSON 文档。该类型可替代过去的 NVARCHAR 存储 JSON，使数据库引擎直接管理 JSON 数据。
• 优势与预期用途： 原生 JSON 类型提高了 JSON 操作性能：解析、检索、修改等内置函数都能利用二进制存储加速运算。此外，它支持存储更大的 JSON 文档（理论上可达 2GB），适合保存配置、日志、半结构化数据等。开发者可以使用 ALTER COLUMN 将现有列转换为 JSON 类型，无缝迁移。总体上，它让数据库对 JSON 数据的处理更高效可靠，简化了面向 NoSQL/混合数据场景的开发。
• 批评与局限性： 目前原生 JSON 类型仍处于预览期，有一些限制。不能直接通过 BULK INSERT 或 OPENROWSET(BULK) 导入 JSON 列，需要使用格式文件指定类型。不支持分布式查询：不能在链路服务器或跨库查询中使用 JSON 列。此外，JSON 类型目前不参与列排序规则（locale）比较等高级功能。社区反馈也指出，对 JSON 的索引和压缩机制仍在完善中。
• 评价与建议： 原生 JSON 类型对开发极为有利，可在开发新应用时优先采用，减少对字符串存储的依赖并提升查询性能。对于已有系统，应评估兼容性问题及限制：在升级前，需要确认不依赖上述受限操作（分布式查询、Bulk 导入等）。在允许的场景下，推荐使用该类型来替代 NVARCHAR(MAX) 存储 JSON，配合后述 JSON 索引使用更佳。

JSON 聚合函数

• 功能概述： 新增 ANSI 标准的 JSON 聚合函数 JSON_OBJECTAGG 和 JSON_ARRAYAGG，用于将关系型数据聚合成 JSON 对象或数组。
• 优势与预期用途： 这组聚合函数让开发者可以在单个查询中将结果集直接构建成 JSON 文档，如一行记录整合为 JSON 对象或将多行合并为 JSON 数组。结合 SQL 的其他聚合（如 STRING_AGG、SUM 等），可以方便地生成嵌套的 JSON 输出，用于 API 返回或复杂报表，无需在应用层再拼接 JSON。
• 批评与局限性： 目前功能相对单纯，没有突出负面反馈。需要注意的是，在极大数据量上执行聚合生成 JSON 时，函数本身的排序和数据转换开销可能较大，需要足够资源。
• 评价与建议： 对于需要将关系数据与 JSON 格式结合的场景（如 REST API 数据输出），应优先采用 JSON 聚合函数，以简化查询逻辑和应用代码。建议结合原生 JSON 类型和索引一起使用，提升生成 JSON 的效率。

JSON 索引（预览）

• 功能概述： SQL Server 2025 预览版提供了 JSON 索引功能，可在 JSON 列上创建索引。该索引对 JSON 的各个键（标量、对象、数组）进行提取，可优化 JSON_VALUE、JSON_PATH_EXISTS、JSON_CONTAINS 等函数的查询。
• 优势与预期用途： JSON 索引本质上是单个索引，可以加速针对 JSON 文档中键/路径的查询，大幅提高对半结构化数据的检索性能。在需要经常查询或过滤 JSON 字段的应用中，通过创建 JSON 索引可避免全表扫描，提升查询效率。开发者可指定对所有路径索引或指定部分路径索引，提高灵活性。
• 批评与局限性： JSON 索引当前为公共预览版功能，功能稳定性和灵活性尚待社区验证。索引创建和维护会带来额外开销；对于动态结构频繁变化的 JSON，索引更新可能影响写入性能。此外，索引支持的功能和配合细节需要参考文档和实践，目前尚未见到公开案例说明全部限制。
• 评价与建议： 如果应用中广泛使用 JSON 存储并且对 JSON 内容有复杂查询需求，可考虑在关键字段上使用 JSON 索引。建议在开发/测试环境进行评估：测试索引对查询性能的提升与写入开销的权衡。在工作负载适合的情况下，优先使用 JSON 索引提升查询效率；但若 JSON 查询较少，可暂时观望功能稳定性和未来升级。

对象存储集成

PolyBase 外部数据源支持

• 功能概述： SQL Server 2025 在 PolyBase 功能上新增本地支持，可直接通过 OPENROWSET 或 CREATE EXTERNAL TABLE 查询 Parquet、CSV、Delta 等文件，以及 Azure Blob Storage (ABS)、Azure Data Lake Storage (ADLS)、Amazon S3 等对象存储中的数据，无需额外安装 PolyBase 查询服务。
• 优势与预期用途： 该增强让开发者可以更轻松地在 T-SQL 中对云端或大数据文件进行查询，免去了传统 ETL 导入数据的繁琐。只需编写一条查询语句，就能联接到外部文件数据源，极大便利了对湖仓数据的实时访问。对混合部署和数据湖分析尤为重要，可跨云跨平台查询数据，简化现代数据架构。
• 批评与局限性： 目前对关系型外部源（如 Oracle、Teradata）仍然需要 PolyBase 查询服务；新功能主要针对文件格式数据源。此外，这些新连接对 2025 预览版生效，而旧版服务器若希望相似功能需升级。开发者需注意配置权限和网络，且暂时不支持某些进阶参数（例如复杂分区）。社区提到该功能可提升开发效率，但目前文档中有些限制条款，需查看 PolyBase 文档。
• 评价与建议： 如果项目涉及跨平台数据集成或需在 SQL 中直接查询云端数据，PolyBase 的这些增强功能非常有用。建议利用这些功能简化外部数据访问流程，尤其在数据湖、混合云分析场景。但应注意验证连接配置与性能，比如并发访问大文件时的资源占用。对于纯关系型数据库对接，仍需保留原有方法；而面对文件/对象存储时，则可优先使用新特性。

云备份与对象存储

• 功能概述： SQL Server 2025 支持将数据库备份直接写入 S3 兼容的对象存储（如 AWS S3）并从中恢复。这在 SQL Server 2022 已引入的 Azure Blob 备份基础上，扩展到了更多云环境。
• 优势与预期用途： 对于混合云部署和多云策略，可将备份文件存放于成本更低的对象存储中，实现远程备份与灾备。开发者无需自行编写脚本搬运备份，通过 BACKUP TO URL 语法即可操作。增强了备份灵活性和恢复选项，便于跨区域、多租户部署。
• 批评与局限性： 按照官方文档，只有 Enterprise、Standard、Web 版支持 S3 备份，Express 等精简版不支持。这意味着小规模或低成本部署需要额外考虑许可和成本。此外，使用对象存储作为备份目标时，要留意网络带宽和存储费用，以及备份/恢复速度可能受限于网络环境。社区提及该功能易于使用，但需结合存储策略和预算规划。
• 评价与建议： 在混合云或多云环境中，云备份到对象存储非常实用。建议在满足版本要求的情况下优先启用，作为扩展的灾备策略。同时，需要在维护成本和性能之间做权衡：合理规划存储生命周期、备份频率和保留策略，避免不必要的费用。对于资源有限环境，要对比对象存储与传统备份方法的成本效益后再决定。

内置 AI 支持

向量数据类型与索引

• 功能概述： SQL Server 2025 提供了新的 VECTOR 数据类型（预览），用于存储向量数据；同时支持构建近似向量索引（基于 DiskANN 引擎）进行相似性搜索。向量数据可用于机器学习和信息检索场景，如图像特征、文本嵌入等。
• 优势与预期用途： 原生向量类型使得相似度搜索和向量运算可在数据库层高效执行。借助向量索引，开发者可以快速查找与给定向量最相似的数据项，极大简化了 AI 应用中的“最近邻搜索”（kNN）任务。在需要在关系数据库中引入机器学习模型或实现文本推荐、分类等场景时，此功能将数据预处理和查询整合到 SQL Server，减少了外部依赖。
• 批评与局限性： 目前向量功能仍在预览阶段，只在部分 Azure SQL 产品（例如 Azure SQL MI）下随 Always-upto-date 策略可用；在本地版 SQL Server 上需等待支持。向量索引的性能依赖于具体实现，DiskANN 有一定的设置要求，对大规模数据需要调优索引参数。此外，向量查询通常是资源密集型操作，需要额外的算力和内存。社区评价新功能前景广阔，但对初期性能和可用性的期望需要控制。另外注意到最大向量维度只有1998，现在许多文本嵌入模型很轻易就达到2000多，因此可能有点鸡肋。
• 评价与建议： 对于需要嵌入 AI/ML 功能的应用，原生向量支持非常值得关注。建议在实验环境中尝试：在模型嵌入（embeddings）和相似度搜索等场景中测试其效果与性能，并根据需要调整索引配置。如系统中已有大量向量数据且计划部署机器学习组件，可考虑尽早引入以简化体系架构。但要注意当前功能的预览性质，生产环境应谨慎部署，并关注微软后续功能更新。

向量函数

• 功能概述： 配套向量类型，SQL Server 2025 引入了一系列向量运算函数（如点积、范数计算等）。开发者可以在 SQL 查询中直接对 VECTOR 列进行数学运算。
• 优势与预期用途： 这些函数简化了向量的操作，在数据库内就能完成诸如计算相似度（如余弦相似度）、归一化等常用机器学习步骤。这样可以避免将数据导出到外部环境进行计算，降低了数据移动成本，提升了整体性能。
• 批评与局限性： 函数本身与向量类型一致，还在预览阶段，仅限于支持的向量类型和算法。大型向量运算可能耗费资源，目前尚无广泛社区性能反馈。
• 评价与建议： 向量函数应与向量类型一起配合使用。在设计包含相似度搜索或机器学习推断的系统时，可以考虑尽快试用，将算法部分嵌入 T-SQL。使用时需要做好性能测试和索引维护工作。如应用场景较少用向量数据，可先观察未来的稳定性更新。

管理外部 AI 模型

• 功能概述： 引入了 CREATE EXTERNAL MODEL 等语句，用以定义外部 AI 模型对象（如调用 OpenAI、Azure OpenAI 或 Ollama 的推理端点）。每个外部模型记录了其地址、类型、凭据等信息，可在 SQL 查询中引用。
• 优势与预期用途： 开发者可通过 SQL 直接调用这些外部模型进行推理，例如获取文本嵌入（embeddings）或生成文本等。将模型调用纳入数据库层，让数据处理和 AI 推理紧密结合，简化了开发流程。例如，可以先在 SQL 中检索数据行，然后直接调用模型进行分析，而不必在应用服务器上额外实现 REST 调用。
• 批评与局限性： 此功能本质上是一种元数据注册，它自身不执行推理，需要外部服务支持。安全性和成本是两大关注点：需要配置数据库凭据访问模型端点，还要考虑调用频次带来的费用。延迟方面，调用外部模型会比纯 SQL 查询慢，还需要考虑网络稳定性。社区认为这是有力特性，但实际收益取决于业务场景，需要在架构中权衡。
• 评价与建议： 对于需要将 AI 功能融入数据库工作流的场景（如在 ETL 或实时查询中生成特征、使用语言模型摘要等），可试验使用外部模型管理功能。建议在正式使用前，对服务调用进行监控和权限控制，确保安全合规。若项目与 AI 需求密切，将该功能作为探索路线；反之则可暂时将模型调用放在应用层，待功能成熟后再迁移到数据库层。

外部 REST/GraphQL 调用 (sp_invoke_external_rest_endpoint)

• 功能概述： SQL Server 2025 增加了 sp_invoke_external_rest_endpoint 存储过程，使 T-SQL 可以直接调用外部 REST 或 GraphQL 接口。可用于触发 Azure Functions、更新 PowerBI 仪表板、访问第三方 API 甚至调用 Azure OpenAI 服务。
• 优势与预期用途： 这一功能让数据库成为第一类的集成引擎：开发者可以在 SQL 中直接完成跨系统交互，无需额外的中间件。例如，可在触发某些业务操作后，立即通过 SQL 执行 HTTP 请求将结果推送到其他系统，实现数据流的自动化和实时化。在微服务架构或多系统集成场景下，这极大简化了架构和部署。
• 批评与局限性： 目前该功能仅在 Azure SQL Database/Managed Instance 等平台提供，对本地 SQL Server 2025 不可用。也就是说，需要借助 Azure Arc 或混合部署来使用。安全方面，需要管理好数据库凭证和外网访问权限。调用外部服务可能增加事务的不确定性与延迟，并引入外部故障风险。社区指出，这是一把双刃剑：方便但需谨慎使用。
• 评价与建议： 如果应用部署在云环境并且需要频繁与其他云服务交互，可优先考虑使用该特性，将逻辑集中在数据库层。对于本地数据库而言，目前建议仍通过应用程序或中间件来实现类似功能，待未来版本支持时再考虑迁移。在启用该功能时，应做好错误处理和监控，确保外部调用的稳定性和安全性。

实时变更事件流 (Change Event Streaming)

• 功能概述： 该功能使 SQL Server 的表 DML 变更（INSERT/UPDATE/DELETE）能实时流式发送到 Azure Event Hubs。变更数据（包括表结构、前值和新值等）以 CloudEvent 格式输出，并可选 JSON 或 Avro 序列化。开发者通过创建“流组”指定要跟踪的表和目标 Event Hub。
• 优势与预期用途： 实时变更流可用于构建事件驱动架构。例如，可即时同步多个系统的数据、触发实时分析，或实现审计监控。相比传统的 CDC 或轮询方式，该功能直接输出到高吞吐的流处理平台，支持多消费者并行处理。它使得关系型数据库与大数据平台、消息队列实现无缝对接，适用于物联网、实时分析和微服务通信场景。
• 批评与局限性： 该功能目前也是预览版，仅支持将事件发送到 Azure Event Hubs（不支持其他 Kafka 或自建消息系统）。需要配置 Azure 资源和身份验证，对仅本地部署的环境支持有限。变更流带来的额外 I/O 和网络开销也需评估。另外，与传统数据库副本相比，它只捕获 DML，对大事务的完整性依赖事务日志，因此可能存在延迟或丢失变更风险（需要适当配置）。由于为新功能，社区使用经验尚少，需重点关注潜在延迟和一致性问题。
• 评价与建议： 对于需要实时监控或分发数据库变更的应用而言，此功能非常有吸引力。建议在已有 Azure 生态（使用 Event Hubs/Synapse/Fabric）的架构中优先采用。使用前应进行压力测试，验证事件消费延迟和吞吐是否满足需求；并对表设计进行优化（如分区、索引）以控制变更捕获负荷。对于纯本地环境或对延迟敏感的场景，可暂时保持传统方法，同时跟踪后续版本对其他目标的支持情况。

并发与性能提升

优化锁机制 (Optimized Locking)

• 功能概述： 优化锁机制通过事务 ID 锁和锁后验证技术，减少对每行或每页的独占锁持有时间。更新大批数据时，会为每行使用即时释放的锁，并仅保持一个小范围锁到事务结束，从而降低锁存储和冲突。
• 优势与预期用途： 此功能可显著减少长事务中的锁内存消耗和阻塞。例如，在更新 1000 行时，传统方式会保持 1000 个行锁到事务结束；优化锁机制下，每更新一行的锁会立即释放，只保留一个事务锁，大大降低锁升级概率。这提高了并发性能，减少阻塞，对 OLTP 大事务（如批量更新、导入）尤其有效。
• 批评与局限性： 目前 SQL Server 2025 版默认未启用优化锁（需手动按数据库开启），而 Azure SQL DB 默认启用。开发者需主动测试并评估这一改变对现有应用的影响。此外，优化锁只作用于 DML 锁，并不影响模式锁等。少数开发者可能担心潜在的故障模式，但微软文档未披露大问题。社区一般认为这是积极改进，但建议逐库评估。
• 评价与建议： 优化锁可以在批量写入场景中带来明显的并发提升。对于对锁冲突敏感的应用，推荐在测试环境中启用并衡量性能变化。如果测得阻塞显著降低且稳定可靠，可逐步在生产启用。一般建议对更新密集的业务首先采用，并密切监控锁统计和执行情况；对于锁争用不严重的系统，可后续考虑使用。

以上列举的功能在 SQL Server 2025 中相对独立，但也有互补之处。例如：JSON 原生类型与 JSON 索引结合使用效果最佳；向量类型常与外部模型管理和事件调用一起用于 AI 工作流。综合考虑利弊，每项新功能都应根据具体场景审慎采用。总体上，SQL Server 2025 大量面向开发者的增强可显著简化现代应用开发，但需谨慎测试、分步部署，以充分发挥它们的价值。**】

参考资料： 根据微软官方文档和社区博客整理等。

叠甲：这些功能仍然是预览版，可能不代表正式版的能力。