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 锁，并不影响模式锁等。少数开发者可能担心潜在的故障模式，但微软文档未披露大问题。社区一般认为这是积极改进，但建议逐库评估。评价与建议： 优化锁可以在批量写入场景中带来明显的并发提升。对于对锁冲突敏感的应用，推荐在测试环境中启用并衡量性能变化。如果测得阻塞显著降低且稳定可靠，可逐步在生产启用。一般建议对更新密集的业务首先采用，并密切监控锁统计和执行情况；对于锁争用不严重的系统，可后续考虑使用。
