MySQL中NOW()与CURRENT_TIMESTAMP完全等价，均返回当前日期时间（默认精度到秒，5.6+支持毫秒如NOW(3)），建表推荐CURRENT_TIMESTAMP（语义明确），查询常用NOW()；注意SYS_DATE()不存在，PostgreSQL的NOW()事务内恒定且带时区，SQL Server应优先用SYSDATETIME()而非GETDATE()，跨库兼容建议应用层生成时间戳或统一用CURRENT_TIMESTAMP并注明以主库时区为准。
MySQL里用NOW()还是CURRENT_TIMESTAMP？
两者在MySQL中完全等价，都返回当前日期时间（精度到秒），且默认带时区上下文（取决于服务器设置）。如果建表时定义DATETIME字段的默认值，推荐用CURRENT_TIMESTAMP，因为语义更明确；纯查询中用NOW()更常见，但本质没区别。
注意：MySQL 5.6+ 支持毫秒级，写成NOW(3)或CURRENT_TIMESTAMP(3)可保留三位小数。别直接用SYS_DATE()——这函数根本不存在，是常见拼写错误。
PostgreSQL必须用NOW()，但行为和MySQL不同
PostgreSQL的NOW()返回TIMESTAMP WITH TIME ZONE，即带UTC偏移的时间戳，且在整个事务中保持不变（不像MySQL每次调用都实时刷新）。如果只想取日期部分，得显式转换：CURRENT_DATE；只取时间用CURRENT_TIME。
容易踩的坑：
- 误以为
NOW()在同一个SQL里多次调用会变化——不会，它冻结在事务开始时刻 - 把
LOCALTIMESTAMP当成无时区版本——其实它和NOW()一样，只是类型默认为TIMESTAMP WITHOUT TIME ZONE - 用
clock_timestamp()替代NOW()来获取实时时间——可以，但它开销略高，仅在需要精确到执行瞬间时才用
SQL Server用GETDATE()，但要注意类型隐式转换
GETDATE()返回DATETIME类型（精度约3.3毫秒，范围1753–9999年）。如果字段是DATETIME2，建议改用SYSDATETIME()——它精度达100纳秒，且范围更大（0001–9999年）。
常见错误：
- 在WHERE条件里写
date_col = GETDATE()——几乎永远不成立，因为时间精度太高，应改用范围比较，比如date_col >= CAST(GETDATE() AS DATE) - 用
GETUTCDATE()却忘了业务逻辑是否真需要UTC——多数系统用本地时间就够了，混用会导致时区错乱 - 在计算列或索引表达式中直接用
GETDATE()——SQL Server不允许，会报错Invalid use of a side-effecting operator
跨数据库写法怎么尽量兼容？
没有银弹。标准SQL只定义了CURRENT_TIMESTAMP，它在MySQL、PostgreSQL、SQL Server里都可用，但行为细节不同：MySQL和PostgreSQL中它是事务常量，SQL Server中每次调用都刷新。所以别指望“一次书写到处运行”。
真正实用的妥协方案：
- 应用层生成时间戳（如Python的
datetime.now()或JS的Date.now()），传参进SQL——最可控，也规避了数据库时区配置差异 - 如果必须用数据库函数，统一用
CURRENT_TIMESTAMP，并在文档里注明“以主库时区为准” - 避免在复杂JOIN或子查询里嵌套多次
NOW()——不同引擎对“同一语句内多次调用是否同步”的实现不一致，结果可能意外
时区才是最大陷阱。哪怕函数名一样，CURRENT_TIMESTAMP在UTC服务器上跑出来的时间，和上海服务器上跑出来的，差8小时——这个没法靠函数选型解决，得靠部署时统一配置或应用层显式指定时区。
