getdate() 不等于事务时间，因为它返回语句执行时的实时系统时钟值，而非事务启动时刻的冻结时间戳；每次调用都随系统时间变化，不绑定事务生命周期，且sql server无内置函数直接获取事务开始时间。
GETDATE() 和 CURRENT_TIMESTAMP 都返回当前会话的系统时间，但它们不反映“事务开始时间”——SQL Server 中没有内置函数能直接获取事务启动时刻的时间戳。
为什么 GETDATE() 不等于事务时间？
GETDATE() 和 CURRENT_TIMESTAMP 是同义词，每次调用都返回语句执行时的系统时钟值，和事务生命周期无关。即使在 BEGIN TRANSACTION 之后多次调用，它仍随系统时间实时变化，不会“冻结”在事务开始那一刻。
- 事务中执行
SELECT GETDATE()两次，结果可能不同（尤其跨秒时） -
BEGIN TRAN; WAITFOR DELAY '00:00:02'; SELECT GETDATE(); COMMIT返回的是 WAITFOR 结束后的时间，不是 BEGIN TRAN 的时间 - 快照隔离（SNAPSHOT 或 READ_COMMITTED_SNAPSHOT）下，事务看到的数据版本基于事务开始时的
tempdb版本时间戳，但这个时间戳不可通过 SQL 函数直接读取
如何近似捕获事务起始时间？
唯一可靠方式是在事务开头显式记录时间到变量或临时表。SQL Server 不提供类似 PostgreSQL 的 transaction_timestamp() 或 Oracle 的 SYSTIMESTAMP（在事务内恒定）机制。
- 使用局部变量：
DECLARE @tx_start DATETIME2 = SYSDATETIME(); BEGIN TRAN; ... -- 后续用 @tx_start - 写入临时表更适用于嵌套过程：
CREATE TABLE #tx_context (start_time DATETIME2); INSERT #tx_context VALUES (SYSDATETIME()); - 避免用
GETDATE()替代 —— 它精度低（毫秒级舍入）、且不支持时区；优先用SYSDATETIME()或SYSDATETIMEOFFSET()
CURRENT_TIMESTAMP 在存储过程或触发器里有什么陷阱？
它只是 GETDATE() 的 ANSI 标准别名，行为完全一致，但容易让人误以为它“绑定事务上下文”。实际在触发器中，它返回触发语句执行时刻的时间，而非事务启动时刻。
- 批量插入 1000 行触发 INSERT 触发器：每行触发一次，
CURRENT_TIMESTAMP可能有微小差异 - 触发器内调用
GETDATE()和CURRENT_TIMESTAMP结果相同，二者无功能区别 - 若需统一时间基准，必须在触发器外预先计算并传参，或用
SET CONTEXT_INFO携带时间值（需手动管理）
事务时间本质是逻辑概念，SQL Server 把它隐藏在内部版本控制机制里，对外不可见。想精确追踪，只能靠人工打点 —— 这不是疏漏，而是设计使然：事务时间不是日志里的一个字段，而是版本链的起点标记。
