now()返回语句启动时刻的固定时间戳，保证事务内一致性；sysdate()每次调用实时获取系统时间，可能因执行延迟产生差异；getdate()在sql server中行为类似sysdate()。
☞☞☞☞点击夸克ai手把手教你，操作像呼吸一样简单！☜☜☜☜☜
NOW() 返回的是语句开始执行时的时间戳，不是实时更新的
在 MySQL 中，NOW() 返回的是该 SQL 语句**启动时刻**的系统时间，整个语句执行过程中多次调用 NOW() 都会返回同一个值。这在 INSERT 或 UPDATE 多行、或子查询中容易引发误解。
- 适用于需要“事务内时间一致性”的场景，比如记录整批操作的统一时间戳
- 不适用于想获取每行计算时的精确时间（比如在 SELECT 中为每行打上“当前毫秒级时间”）
- 若需实时时间，改用
SYSDATE()—— 它随每次调用动态求值
SYSDATE() 是 MySQL 的“真实时”函数，但默认不走查询缓存
SYSDATE() 在 MySQL 中返回的是函数**实际执行那一刻**的系统时间，哪怕在同一语句中多次出现，也可能因微秒级延迟而不同（尤其在高并发或慢查询中）。
- 在
SELECT SYSDATE(), SLEEP(1), SYSDATE()中，两个SYSDATE()结果通常相差约 1 秒 - 它绕过查询缓存（即使整个语句其他部分可缓存），所以性能略低于
NOW() - 注意：MySQL 8.0+ 默认启用
sysdate_is_now系统变量为 OFF，不影响行为；但某些旧版中间件或 ORM 可能误将SYSDATE()当作NOW()处理
GETDATE() 是 SQL Server 的等效函数，语义接近 MySQL 的 GETDATE() ≈ SYSDATE()
SQL Server 没有 NOW()，它的 GETDATE() 行为更像 MySQL 的 SYSDATE()：每次调用都重新取系统时钟，同一语句中多次出现可能返回不同值（尽管概率极低，取决于执行速度）。
- SQL Server 还提供
SYSDATETIME()（精度达 100 纳秒）和GETUTCDATE()（UTC 时间），比GETDATE()更推荐用于新项目 - 跨数据库迁移时，把 MySQL 的
NOW()直接换成 SQL Server 的GETDATE()可能导致逻辑偏差——因为前者是语句级快照，后者是调用级采样 - PostgreSQL 对应的是
NOW()（行为同 MySQL 的NOW()），而CURRENT_TIMESTAMP是其同义词；若需实时，得用clock_timestamp()
别只看函数名，先确认数据库类型和版本再选函数
三个函数名字相似，但语义分属不同体系：NOW() 和 SYSDATE() 是 MySQL 特有；GETDATE() 是 SQL Server / Sybase；PostgreSQL 和 Oracle 各自另有实现。直接复制粘贴易出错。
- MySQL 5.6+ 中
NOW()和CURRENT_TIMESTAMP完全等价；SYSDATE()是独立函数，不可互换 - SQL Server 中没有
SYSDATE()，用了会报错：Invalid object name 'SYSDATE' - Oracle 用
SYSDATE（无括号，是伪列），它行为类似 MySQL 的SYSDATE()，但不能在函数参数里直接写成SYSDATE()
真实业务中，最常被忽略的是「时间一致性预期」：你以为要的是“这批数据入库的统一时间”，结果用了 SYSDATE()，导致同一 INSERT 语句里不同行的 created_at 字段差了几毫秒——这在金融对账或幂等控制里可能成为隐患。
