NOW()和CURRENT_TIMESTAMP在MySQL中完全等价，是源码级同义词；PostgreSQL中二者有本质区别：NOW()是函数，CURRENT_TIMESTAMP是关键字；SQLite仅支持CURRENT_TIMESTAMP作默认值，无NOW()函数。
MySQL里NOW()和CURRENT_TIMESTAMP到底是不是一回事
完全一样，连函数签名、返回类型、时区行为都一致——它们是同义词，不是近似等价，是MySQL源码里直接互换的别名。
实操建议：
-
NOW()和CURRENT_TIMESTAMP（不带括号）在MySQL中可互换使用，比如SELECT NOW(), CURRENT_TIMESTAMP;返回完全相同结果 - 加括号的
CURRENT_TIMESTAMP()也合法，但括号无实际作用，不推荐写，容易让人误以为能传参 - 两者都受会话时区影响：
SET time_zone = '+08:00';后再调用，结果就是东八区时间 - 注意：如果字段定义为
TIMESTAMP DEFAULT CURRENT_TIMESTAMP，这里不能写成NOW()，语法报错——只有CURRENT_TIMESTAMP（不带括号）被允许作为列默认值
PostgreSQL中NOW()和CURRENT_TIMESTAMP的区别在哪
有本质区别：一个是函数，一个是关键字；返回值类型不同，精度行为也不同。
常见错误现象：用 NOW()::date 截日期没问题，但 CURRENT_TIMESTAMP::date 在某些老版本里会报错或截断异常。
实操建议：
-
NOW()是函数，返回timestamp with time zone，可直接参与运算，比如NOW() + INTERVAL '1 day' -
CURRENT_TIMESTAMP是SQL标准关键字，行为更“静态”，虽也返回带时区时间，但在子查询或表达式中有时被优化器提前求值（尤其嵌套视图里） - 精度差异：默认都带6位微秒，但
CURRENT_TIMESTAMP(3)可指定精度（如毫秒），而NOW(3)在PostgreSQL中不支持参数——会报错function now(integer) does not exist - 兼容性提示：跨数据库迁移时，若代码里混用二者，PostgreSQL能跑，MySQL可能因语法或默认值限制失败
SQLite里没有NOW()，CURRENT_TIMESTAMP怎么用才不出错
SQLite压根没有 NOW() 函数，CURRENT_TIMESTAMP 是关键字，且只能用于列默认值，不能在普通SELECT里直接调用。
常见错误现象：SELECT CURRENT_TIMESTAMP; 在SQLite中会报错 no such column: CURRENT_TIMESTAMP。
实操建议：
- 要用当前时间，必须写成
SELECT datetime('now');或SELECT strftime('%Y-%m-%d %H:%M:%f', 'now'); -
CURRENT_TIMESTAMP只能在建表时当默认值用：CREATE TABLE log (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP); - 注意时区：SQLite所有时间函数默认按本地时区处理，不带时区信息；
'now'字符串不自动转UTC，也不受系统TZ环境变量影响 - 性能影响：
datetime('now')每次调用都实时计算，放在WHERE条件里无法利用索引（除非你建了函数索引，但SQLite 3.30+才支持）
跨数据库写SQL时，如何安全地取当前时间
没有银弹，但可以收敛到一个最小可行写法，避开各库最坑的边界。
实操建议：
- 优先用标准SQL写法：
CURRENT_TIMESTAMP（不带括号），它在MySQL、PostgreSQL、SQL Server、Oracle中都可用，且语义稳定 - 避免在表达式中直接写
NOW()—— SQLite不认，SQL Server里它是非标准扩展，Oracle里根本不存在 - 如果必须动态计算（比如加减时间），用字符串字面量：
SELECT CURRENT_TIMESTAMP + INTERVAL '1 hour';在MySQL/PG可用，但SQLite需改写为datetime('now', '+1 hour')，这时就得靠应用层判断方言 - 最容易被忽略的一点：所有这些函数返回的都是“执行时刻”的时间，不是事务开始时间。如果你在长事务里多次调用，结果可能不同——这点在MySQL的RC隔离级别下尤其明显
