SQL Server 2022 不记录时钟同步事件，需通过外部脚本采集 W32Time 偏差数据并存入自定义表，方可使用 AVG、DATE_BUCKET 等聚合分析；sys.dm_os_sys_info 和 Agent 日志均无法提供有效偏差值。
SQL Server 2022 本身不记录、不聚合“时钟同步事件”——这类操作属于系统级运维行为，不是数据库表里的数据行。想用聚合函数处理它，得先有结构化的时间戳日志，否则 AVG、COUNT、DATE_BUCKET 全都无从下手。
时钟同步事件在哪？根本没进 SQL Server 表里
SQL Server 不自动采集服务器系统时钟是否被 NTP 或域策略调整过。你看到的“同步目标服务器时钟”功能（通过 SQL Server Agent 的“同步时钟”指令）只是向目标服务器发一条命令，不返回执行结果，也不写入任何系统视图或日志表。
- Windows 事件日志里可能有
W32Time相关事件（ID 129、144 等），但这是 OS 层，SQL Server 无法直接SELECT它 -
sys.dm_os_sys_info只返回当前启动时间，不反映后续时钟跳变 - 哪怕你在 Agent 作业里手动插入一条“已同步”记录，那也只是单点标记，不是带偏差值的事件流
如果真要聚合，必须自己建表存偏差数据
唯一可行路径：用外部脚本（PowerShell / Windows Task Scheduler）定期调用 w32tm /query /status，解析出 ReferenceTime 和本地时间差，再把结果 INSERT 到自定义表中。之后才能用 SQL Server 聚合。
- 建表示例：
CREATE TABLE dbo.clock_sync_log ( log_time DATETIMEOFFSET PRIMARY KEY, ref_time DATETIMEOFFSET, offset_ms BIGINT, source NVARCHAR(50) ); - 聚合偏差趋势：
SELECT DATE_BUCKET(minute, 5, log_time) AS bucket, AVG(offset_ms) AS avg_offset_ms, STDEV(offset_ms) AS jitter_ms FROM dbo.clock_sync_log WHERE log_time >= DATEADD(hour, -24, GETUTCDATE()) GROUP BY DATE_BUCKET(minute, 5, log_time) ORDER BY bucket; - 注意：
offset_ms是带符号整数（正=本地快，负=本地慢），用AVG合理；但若想看最大漂移，得用MAX(ABS(offset_ms))
别误用 DATETRUNC 或 FOR JSON 模拟“同步事件”
有人试图用 DATETRUNC(second, GETDATE()) 频繁采样来“检测时钟跳跃”，这完全无效：
- 两次查询间隔本身就有毫秒级不确定性，
GETDATE()返回的是 SQL Server 缓存的时间戳，不是实时系统时钟 -
FOR JSON PATH或JSON_OBJECTAGG只能格式化已有数据，不能凭空生成同步事件 - 哪怕把 Agent 作业历史表
msdb.dbo.sysjobhistory当作“同步日志”，里面也只记成功/失败状态，没有时间偏差数值，AVG或STDEV会报错或返回无意义结果
真正要监控时钟稳定性，得靠 Windows 性能计数器（\W32Time\Seconds Since Last Sync）或专用 NTP 监控工具；SQL Server 只能当存储和轻量分析层，前提是数据已经以正确结构落库。
