MySQL中推荐用NOW()，因其更直观常用；若需跨数据库兼容则用CURRENT_TIMESTAMP()，二者功能等价但语法细节不同。
MySQL 里用 NOW() 还是 CURRENT_TIMESTAMP？
两者在 MySQL 中完全等价，都返回当前会话时区下的系统时间（精确到秒或微秒，取决于是否带精度参数）。NOW() 更常用、更直觉，但如果你写跨数据库兼容的 SQL，CURRENT_TIMESTAMP 是 SQL 标准写法，部分 ORM 或迁移工具更倾向它。
注意：不要用 SYS_DATE() 或 GETDATE() —— 那是 Oracle/SQL Server 的函数，MySQL 会直接报错 FUNCTION SYS_DATE does not exist。
-
NOW()和CURRENT_TIMESTAMP都受会话时区影响，不是 UTC 时间；改时区后结果会变 - 需要微秒精度？写成
NOW(6)或CURRENT_TIMESTAMP(6) - 如果只想要日期部分，用
CURDATE()；只要时间部分，用CURTIME()
PostgreSQL 怎么取服务器时间？别漏掉括号
PostgreSQL 必须加括号：NOW() 是标准写法，CURRENT_TIMESTAMP 也行，但不加括号（比如写成 CURRENT_TIMESTAMP 无括号）会被当作类型名，导致语法错误 syntax error at or near "CURRENT_TIMESTAMP"。
另外，CLOCK_TIMESTAMP() 和 NOW() 表面一样，但关键区别在于：前者每次调用都重新获取时间（适合在函数内多次取时间点），后者在事务开始时就固定了值（同一事务中多次调用返回相同时间）。
- 默认返回带时区的
timestamptz类型；要转成本地时区可加AT TIME ZONE 'Asia/Shanghai' - 如果只需要日期，用
CURRENT_DATE（不带括号也合法，但建议统一写CURRENT_DATE()避免混淆） - 避免用
TIMEOFDAY()——它返回字符串，不方便计算或比较
SQL Server 中 GETDATE() 和 SYSDATETIME() 差在哪？
GETDATE() 返回 datetime 类型（精度 3.33ms，范围 1753–9999），而 SYSDATETIME() 返回 datetime2(7)（精度 100ns，范围 0001–9999）。绝大多数新项目应该优先用 SYSDATETIME()，尤其涉及毫秒级日志或排序时，GETDATE() 容易因精度不足导致时间戳重复。
-
GETUTCDATE()和SYSDATETIMEOFFSET()分别用于 UTC 时间和带时区的时间，别混用 - ORM 如 Entity Framework Core 默认映射
DateTime.Now到GETDATE()，如需更高精度得显式改写 SQL 或配置类型映射 - 触发器或默认约束中用
GETDATE()没问题，但若字段定义为datetime2，用SYSDATETIME()更匹配类型
跨数据库写法怎么尽量少改？用 CURRENT_TIMESTAMP 但注意括号
CURRENT_TIMESTAMP 在 MySQL、PostgreSQL、SQL Server、Oracle 中都支持，但行为细节不同：MySQL/PostgreSQL 要括号，SQL Server 允许无括号（但有括号更安全），Oracle 则严格要求无括号。最稳妥的“最小公分母”写法是带括号的 CURRENT_TIMESTAMP() —— 它在前三者中都有效，在 Oracle 中虽不标准但多数版本也兼容（或可通过视图/别名兜底）。
真正难搞的是时区处理：各数据库对会话时区、存储时区、显示时区的处理逻辑差异很大。如果业务强依赖 UTC 时间，别依赖函数自动转换，直接在应用层生成 UTC 时间再传入，比在 SQL 里反复 AT TIME ZONE 或 CONVERT_TZ 更可靠。
时区和精度是实际项目中最容易被忽略的两个点，一不留神就会在日志对齐、定时任务、分布式锁场景出问题。
