getdate() 返回服务器本地时区的 datetime 值，精度 3.33ms，非 utc 也非客户端时间；误用于跨时区场景、高精度比较或大表 where 条件易引发问题，推荐按需选用 getutcdate()、sysdatetime() 或 sysdatetimeoffset()。
GETDATE() 返回的是服务器本地时区的时间，不是 UTC，也不是客户端时间——这点必须先确认清楚，否则后续所有时间比对、存储、转换都会出错。
GETDATE() 的基本用法和常见误用
它不带参数，直接调用即可返回 datetime 类型值（精度 3.33ms，范围 1753–9999 年）。很多人在 WHERE 条件里写 WHERE create_time > GETDATE()，结果查不到数据——因为 create_time 是 datetime2 或带毫秒的 datetime，而 GETDATE() 的精度较低，可能导致隐式截断或比较偏差。
- 只在需要“服务器当前时刻”语义时用，比如记录日志、生成默认时间戳
- 不要用于跨时区系统的时间统一基准；改用
SYSDATETIMEOFFSET()或GETUTCDATE() - 避免在大表 WHERE 中高频调用（虽函数本身轻量，但若嵌套在子查询或 JOIN 条件中可能影响执行计划）
GETDATE() 和其他时间函数的区别在哪
SQL Server 有多个“当前时间”函数，选错会埋坑。比如 GETDATE() 和 GETUTCDATE() 都返回 datetime，但前者是本地，后者是 UTC；而 SYSDATETIME() 返回 datetime2(7)，精度达 100ns，且不受服务器时区设置影响（但仍是本地时区值）。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
-
GETDATE()：datetime，本地时区，3.33ms 精度 -
GETUTCDATE()：同上类型，但值为 UTC 时间 -
SYSDATETIME()：datetime2(7)，本地时区，100ns 精度 -
SYSDATETIMEOFFSET()：带时区偏移的datetimeoffset，最适合作为全局时间基准
在 INSERT/UPDATE 中使用 GETDATE() 的注意事项
作为列默认值很常见，但要注意：如果字段定义为 datetime，而插入时显式传了 GETDATE()，SQL Server 不会自动做时区转换；更关键的是，如果该列有索引，且你常按时间范围查询，建议统一用 datetime2 类型——datetime 在排序、范围扫描时可能因精度截断导致边界行为异常。
- 建表时设默认值：
created_at datetime DEFAULT GETDATE() - 但推荐写成：
created_at datetime2(3) DEFAULT SYSDATETIME()（兼顾精度与存储开销） - 如果应用层已处理时区，数据库应统一存 UTC，此时默认值该用
GETUTCDATE() - 触发器里用
GETDATE()要小心：事务回滚后，时间戳不会“撤销”，它只是快照
真正容易被忽略的是：SQL Server 实例启动后，GETDATE() 的底层依赖是 Windows 系统时钟，一旦服务器时间被手动调整（比如 NTP 同步跳变），它会立刻反映，不会平滑过渡——这对金融类按毫秒计费或实时风控场景可能造成逻辑断层。
