预览功能(preview_features)
启用 preview_features 数据库作用域配置,以测试和探索向量索引等预览功能。此设置允许您即使在 sql server 正式发布后,仍可使用部分预览功能。 通过此配置启用的功能将在未来的累积更新中正式可用。一旦某个功能通过累积更新正式可用,该功能将不再需要 preview_features 配置。 这些功能仅供开发或测试使用,不建议在生产环境中使用。
use hellasgatev2 go select * from sys.database_scoped_configurations where [name] = 'preview_features' go alter database scoped configuration set preview_features = on; go
扩展事件会话加入时间限制选项
- 说明
- 带 max_duration 的自动停止 现在可以在创建或修改事件会话时指定 max_duration(以秒为单位),使其在设定时间后自动停止扩展事件会话。
- 资源管理 这有助于防止会话无限运行,避免消耗资源并生成过多诊断数据。
- 手动控制仍可用 可以随时使用
alter event session ... state = stop手动停止扩展事件会话。 - 灵活修改 可以使用
alter event session更改或移除扩展事件会话的时间限制,但会话必须先停止扩展事件会话。 - 系统视图支持
sys.server_event_sessions视图包含max_duration列,显示扩展事件会话的持续时间(0 表示无限制)。
- 示例
create event session [timeboundsession] on server add event sqlserver.sql_statement_completed with (max_duration = 600, startup_state = off); -- (例如 10分钟,单位秒) alter event session [timeboundsession] on server with (max_duration = 1200); -- 修改为20分钟 alter event session [timeboundsession] on server with (max_duration = unlimited); alter event session [timeboundsession] on server state = stop;
优化的 sp_executesql存储过程
概述(overview)
- 串行编译(serialized compilation)
启用后,sp_executesql 批处理会像存储过程一样编译 —— 仅一个会话进行编译,其他会话等待,减少冗余执行计划的生成。
- 执行计划重用(plan reuse)
首次编译后,其他会话会重用缓存的执行计划,而非自行编译,提升性能和缓存效率。
- 编译锁机制(compile lock mechanism)
编译锁确保同一时间仅一个会话进行编译,防止相同批处理的并行编译。
- 推荐设置(recommended settings)
为获得最佳效果,若启用了自动更新统计信息,还应启用async_stats_update_wait_at_low_priority,以避免长时间等待和排他锁。
- 使用 t-sql 启用(enable with t-sql)
alter database scoped configuration set optimized_sp_executesql = on;
执行计划缓存(plan cache)
- 启用optimized_sp_executesql可对 sql server 2025 的执行计划缓存产生积极影响。
减少执行计划冗余(reduced plan duplication) 相同的 sp_executesql 批处理(排除参数值)将仅编译一次并共享同一执行计划,最大程度减少执行计划缓存中的冗余条目。
- 提升执行计划重用率(improved plan reuse)
后续执行将重用已编译的执行计划,这可提升性能并减少编译期间的 cpu 使用率。
- 串行编译(serialized compilation)
同一时间仅一个会话编译批处理,其他会话等待或重用执行计划 —— 这避免了同一逻辑的多次同时编译。
- 降低缓存碎片(lower cache fragmentation)
通过避免同一执行计划的多个版本,缓存保持更整洁、更高效。
- 首次编译期间的潜在等待(potential waits during first compilation)
会话在首次执行期间可能短暂等待编译锁,但这通常被长期的缓存收益所抵消。
内存使用(memory usage)
启用optimized_sp_executesql可通过改进执行计划的处理方式,对 sql server 2025 的内存使用产生积极影响。
- 内存使用优势如下
- 更少的冗余执行计划(fewer duplicate plans)
- 更整洁的执行计划缓存(cleaner plan cache)
- 更低的编译开销(lower compilation overhead)
- 潜在注意问题
- 初始编译锁等待(initial compile lock waits)
- 执行计划缓存压力降低(plan cache pressure reduction)
zstd 数据库备份压缩算法
- 更快而且更高效
- 与旧的 '
ms_xpress' 算法相比,zstd 提供了更优的速度和压缩比。 - 执行备份时使用指定的压缩算法
- 与旧的 '
backup database [databasename] ... with compression (algorithm = zstd) -- 备份语句,指定压缩算法为 zstd
- 服务器范围的默认设置
使用以下语句将 zstd 设置为所有备份的默认压缩算法:
-- 压缩算法取值:0 = ms_xpress(默认),1 = 无,2 = xpress,3 = zstd exec sp_configure 'backup compression algorithm', 3; -- 配置备份压缩算法为 zstd reconfigure; -- 使配置生效
内存优化(xtp)相关文件和文件组的移除
现在可通过删除所有内存优化文件和文件组,完全移除内存优化oltp的相关表和数据文件—— 这在早期版本中无法实现。
- 验证步骤
- 使用
sys.dm_db_xtp_undeploy_status检查是否使用了内存优化表(deployment_state = 1 或 2)。
select * from sys.dm_db_xtp_undeploy_status;
- 删除所有内存优化表相关对象
在移除数据文件之前,必须删除所有内存优化表、表类型和本机编译的存储过程。
- 移除文件和文件组
使用 alter database ... remove file 和 alter database ... remove filegroup来删除最后一个文件和文件组。
- 长时间运行的移除过程
如果移除停滞,执行 checkpoint 命令并监控 sys.dm_db_xtp_undeploy_status视图以跟踪进度并解决事务日志截断问题。
列存储索引的改进
- 有序非聚集列存储索引
通过保持非聚集列存储索引数据的排序状态,提升了实时运营分析htap场景中的查询性能。适用于对运营数据频繁执行分析查询的场景。sql server 2022已经提供了有序聚集列存储索引功能。
- 有序列存储索引的联机创建 / 重建
现在可在create index或alter index语句的order子句中使用online = on。即使是有序列存储索引,也能在索引创建或重建期间实现停机时间最小化。
- 有序聚集列存储索引的排序质量改进
在联机创建有序聚集列存储索引时,sql server 现在使用tempdb数据库进行排序,而非内存排序。若maxdop = 1,索引生成的列段将完全有序且无重叠,提升查询性能(通过列段消除)。虽然可能因tempdb数据库 的i/o 增加从而增加构建时间,但在多数场景下收益超过成本。
- 收缩lob页面的改进
列存储索引使用lob页面,dbcc shrinkdatabase和dbcc shrinkfile现在可移动列存储索引中的 lob 数据页。这使得收缩操作在回收空间时更有效,此前版本中这一能力受限。
变更跟踪(change tracking)改进
- 新清理策略
为大型变更跟踪辅助表引入自适应浅度清理。
以增量步骤运行,减少资源使用并提升可扩展性。
- 默认启用
在 sql server 2025 中,自适应浅度清理默认启用。
它取代了 sql server 2022 及更早版本中使用的旧深度清理方法。
若要禁用自适应浅度清理,请全局启用trace flag跟踪标志 8273。
- 安全清理点
清理基于由保留期和清理深度确定的安全点。
有助于避免大型表上的长时间阻塞操作。
- 收益
减少清理期间的 cpu 和 i/o 峰值。
对于具有大型变更跟踪辅助表的环境更高效。
alwayson可读辅助副本的持久化统计信息
- 自动统计信息持久化
可读辅助副本上创建的临时统计信息,现在会自动持久化到主副本。
一旦持久化,这些统计信息会在所有副本间同步,从而提升查询性能和一致性。
- 无需跟踪标志
与 sql server 2022(需要跟踪标志 12606)不同,该功能在 sql server 2025 中默认启用。 在 sql server 2025 中使用跟踪标志 12606 会禁用该功能。
- sys.stats 视图中的新字段
replica_role_id指示副本角色(1 = 主副本,2 = 辅助副本,依此类推)。replica_role_desc描述副本角色。replica_name创建统计信息的副本名称。
- 功能亮点
- 即使完成持久化,临时统计信息仍会保留在辅助副本上。
- 优化器会使用最佳可用的统计信息,无论其来源。
- 辅助副本仍可基于自身的数据视图刷新过期统计信息。
- 监控与故障排除
- 使用扩展事件(
persisted_stats_operation)监控持久化操作。 - 常见错误消息包括:
- 9131:功能已禁用
- 9136:表/索引已删除
- 9139:统计信息过大无法发送
对tempdb数据库启用加速数据库恢复
现在可以对tempdb数据库启用加速数据库恢复功能
收益
- 事务即时回滚
- 主动事务日志截断
- 有助于防止长时间事务回滚和 tempdb 事务日志空间耗尽(这类情况可能导致数据库停机)
重要性
在早期版本中,即使采用最小日志记录,tempdb 中长时间运行或失败的事务(例如涉及临时表或表变量的事务)也可能会导致:
- 事务日志高使用率
- 事务回滚延迟
- 应用程序中断
示例代码
-- 启用 tempdb 的加速数据库恢复
alter database [tempdb]
set accelerated_database_recovery = on;
-- 验证 tempdb数据库是否启用了加速数据库恢复(adr)
select name,
is_accelerated_database_recovery_on
from sys.databases
where name = 'tempdb';tempdb数据库空间资源治理
- 背景
防止失控查询或工作负载消耗过多的 tempdb数据库空间。
通过实施每个工作负载的限制,帮助提高可靠性并避免中断。
- 设置方式
可以按工作负载组设置 tempdb 空间限制,方式如下:
group_max_tempdb_data_mb -- 以 mb 为单位的固定大小。 group_max_tempdb_data_percent -- 占 tempdb 总大小的百分比。 -- 若两者都设置,固定限制优先。
- 监控资源使用
sys.resource_governor_workload_groups视图显示已配置的限制
sys.dm_resource_governor_workload_groups视图显示当前和峰值的 tempdb 使用率
扩展事件:tempdb_data_workload_group_limit_reached 当某个工作负载组超出其限制时触发
- 最佳实践
避免将限制设置得过低,尤其是默认工作负载组。
如果工作负载不太可能同时达到峰值,可在多个组之间超额配置限制(例如,总限制超过 tempdb 的 100%)。
预先设置好tempdb 数据文件大小和增长大小,并正确配置 maxsize 和 filegrowth,以使用基于百分比的限制。
- 限制
仅适用于tempdb数据文件,不适用于事务日志文件。
版本存储的使用(例如,用于加速数据库恢复(adr)的部分)不受治理。
空间按 8 kb 页跟踪,即使是部分使用的页也会被跟踪。
- 示例代码
配置 tempdb 空间资源调控器
-- 启用资源调控器 alter resource governor reconfigure; -- 创建资源池 create resource pool rg_tempdb_pool; -- 创建带有 tempdb 空间限制(例如,500 mb)的工作负载组 create workload group wg_tempdb_group using rg_tempdb_pool with (group_max_tempdb_data_mb = 500 -- 或使用 group_max_tempdb_data_percent = 10 ); -- 重新配置资源调控器 alter resource governor reconfigure;
监控 tempdb 使用率
-- 监控 tempdb 使用情况
-- 按工作负载组查看当前 tempdb 使用情况
select
wg.name as 工作负载组,
wg.group_id,
wg_stats.total_allocated_tempdb_kb / 1024.0 as 已使用tempdb_mb,
wg_stats.max_allocated_tempdb_kb / 1024.0 as tempdb_mb_峰值
from sys.dm_resource_governor_workload_groups as wg_stats
join sys.resource_governor_workload_groups as wg
on wg_stats.group_id = wg.group_id;使用扩展事件监控限制违规
-- 使用扩展事件监控限制违规
create event session [tempdblimitmonitor] on server
add event sqlserver.tempdb_data_workload_group_limit_reached
add target package0.event_file
(
set filename = n'tempdblimitmonitor.xel',
max_file_size = 10,
max_rollover_files = 5
)
with (startup_state = on);
go优化锁定
什么是优化锁定
- 一种新的锁定机制,可减少锁内存使用、最小化阻塞并避免锁升级。
- 旨在为高吞吐量事务工作负载提升并发性和性能。
核心组成
- 事务id锁
- 每一行的最后存储修改它的
事务id。 - 不再持有大量行/页锁,而是持有一个单独的
tid锁,直到事务结束。 - 行/页锁在修改后立即释放。
- 限定后锁定
- 使用最新提交的行版本评估谓词,而不获取锁。
- 仅在某行符合修改条件后才获取锁。
- 减少阻塞并提升并发性。
功能可用
| 平台 | 可用 | 默认启用 |
|---|---|---|
| sql server 2025 (17.x) | ✔️ | ❌ |
| azure sql 数据库 | ✔️ | ✔️ |
| microsoft fabric 中的 sql 数据库 | ✔️ | ✔️ |
| azure sql 托管实例(autd) | ✔️ | ✔️ |
| sql server 2022 及更早版本 | ❌ | ❌ |
启用优化锁定
示例代码
alter database [yourdatabasename] set optimized_locking = on;
前提条件
- 数据库必须已经启用了加速数据库恢复(adr)。
- 为了充分获得限定后锁定(laq)的优势,数据库应打开读已提交快照(rcsi)隔离级别
alter database [你的数据库名] set read_committed_snapshot on;
监控
开启了优化锁定之后,使用下面手段监控锁的情况
- 使用
sys.dm_tran_locks视图观察锁行为。 - 新增的等待类型:
lck_m_s_xact_read、lck_m_s_xact_modify。 - 扩展事件
lock_after_qual_stmt_abort当 laq(限定后锁定)被中止并重试时触发。 - 扩展事件
locking_stats锁使用情况和 laq/tid 活动的定期汇总。
到此这篇关于sql server 2025数据库引擎新特性汇总的文章就介绍到这了,更多相关sql server 2025数据库引擎内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
发表评论