SYSUTCDATETIME() 不可用 GETUTCDATE() 替代，因其精度达100纳秒（datetime2(7)），而后者仅约3.33毫秒（datetime）；高精度对分布式事务、审计日志及微秒级排序/去重至关重要。
SYSUTCDATETIME() 返回的是 UTC 时间，精度达 100 纳秒（即 datetime2(7) 类型），不带时区偏移信息，但比 GETUTCDATE() 更精确。它适合需要高精度、跨时区一致时间戳的场景，比如分布式事务日志、审计时间戳、或与外部系统对齐 UTC 时间点。
为什么不能用 GETUTCDATE() 替代 SYSUTCDATETIME()？
两者都返回 UTC 时间，但关键差异在精度和类型：
-
GETUTCDATE()返回datetime，精度只有约 3.33 毫秒（小数位最多 3 位），且底层用旧 API； -
SYSUTCDATETIME()返回datetime2(7)，小数位最多 7 位（如2026-09-29 20:24:15.1234567），底层调用 WindowsGetSystemTimeAsFileTime()，精度固定为 100 纳秒； - 在 ORDER BY、窗口函数、或需要微秒级排序/去重的场景中，
GETUTCDATE()可能因精度不足导致多行“时间相同”，而SYSUTCDATETIME()能更好区分先后。
直接赋值或插入时要注意列类型匹配
若目标列为 datetime 或 datetime2(3)，SQL Server 会静默截断精度——不是报错，而是把 .1234567 强制变成 .123 或更粗粒度，且不提示。
- 建表时显式用
datetime2(7)：CREATE TABLE events (id INT, ts datetime2(7) NOT NULL DEFAULT SYSUTCDATETIME());
- 已有
datetime列想升级？不能直接ALTER COLUMN ... datetime2(7)，需先ADD新列，迁移数据，再DROP旧列； - INSERT 时不加类型转换即可：
INSERT INTO events (ts) VALUES (SYSUTCDATETIME());
——前提是列是datetime2(7)； - 如果列是
datetime，哪怕写成CONVERT(datetime2(7), SYSUTCDATETIME())插入，最终存进去仍是datetime精度，白转。
和 SYSDATETIME()、SYSUTCDATETIME() 容易混淆的点
三者都是高精度函数，但语义不同，选错会导致逻辑错误：
-
SYSDATETIME()：服务器本地时间（含夏令时），datetime2(7)，无偏移； -
SYSUTCDATETIME()：对应时刻的 UTC 时间，datetime2(7)，无偏移； -
SYSDATETIMEOFFSET()：服务器本地时间 + 当前系统时区偏移（如-07:00），datetimeoffset(7)； - 别用
SYSUTCDATETIME()去“模拟本地时间”——它不包含偏移，也无法反推本地时间（除非你知道当前时区且无夏令时波动）； - 若业务要求“所有记录按 UTC 对齐”，就用
SYSUTCDATETIME()；若要“用户看到自己本地时间”，应用层处理更安全，数据库里仍存 UTC。
索引与确定性限制必须提前知道
SYSUTCDATETIME() 是不确定性函数（nondeterministic），这意味着：
- 不能用于计算列并建立索引；
- 不能在视图上基于它创建唯一索引或聚集索引；
- 不能在内联表值函数中作为常量表达式使用；
- 如果你试图在
WHERE中写ts = SYSUTCDATETIME()做实时比对，每次执行都会重新求值，无法利用索引加速——得靠参数化或先查后比。
datetime2(3) + SYSDATETIME() 就够了；但像金融撮合、链路追踪 trace_id 生成、或高并发幂等判断，漏掉那 4 位微秒可能让两条本应严格有序的操作变成“同时发生”，进而触发竞态逻辑。 
