MySQL中查当前时间用NOW()或CURRENT_TIMESTAMP均可，二者等价且返回服务端时区时间；PostgreSQL中now()事务内稳定，CLOCK_TIMESTAMP()才实时；SQL Server推荐SYSDATETIME()；SQLite用datetime('now')。
MySQL 怎么查当前时间？用 NOW() 还是 CURRENT_TIMESTAMP？
两者在绝大多数场景下完全等价，都返回服务端当前的日期时间（带秒，精度通常为秒或微秒）。NOW() 更常用、更直白；CURRENT_TIMESTAMP 是 SQL 标准写法，某些 ORM 或迁移工具里会偏好它。
注意：它们都依赖 MySQL 服务端系统时区，不是客户端本地时间。如果服务端时区设成 +00:00，但你的应用在东八区，直接用 NOW() 就会差 8 小时。
- 想确认服务端时区？执行
SELECT @@time_zone; - 临时切换会话时区？
SET time_zone = '+08:00';再查NOW() - 不建议在 INSERT 中长期依赖
NOW()做业务时间戳——万一 DBA 调了服务器时间，历史记录就乱了
PostgreSQL 查当前时间该用 now() 还是 CURRENT_TIMESTAMP？
和 MySQL 类似，now() 和 CURRENT_TIMESTAMP 在 PostgreSQL 中也行为一致，都返回事务开始时刻的时间戳（关键点！）。
这意味着：同一个事务里多次调用 now()，结果完全相同，不会随真实时间推移而变。这对一致性要求高的审计日志或版本控制很关键，但如果你真要“此刻实时时间”，得用 CLOCK_TIMESTAMP()。
-
now()：事务内稳定，适合默认创建时间字段（如created_at TIMESTAMP DEFAULT now()） -
CLOCK_TIMESTAMP()：每次调用都取系统真实时间，适合监控打点、性能采样 - 别误用
TIMEOFDAY()—— 它返回字符串，不是TIMESTAMP类型，参与计算前得显式转换
SQL Server 里 GETDATE() 和 SYSDATETIME() 差在哪？
GETDATE() 返回 DATETIME 类型（精度 3.33 毫秒，范围 1753–9999），SYSDATETIME() 返回 DATETIME2(7)（精度 100 纳秒，范围 0001–9999）。新项目无脑选后者。
容易踩的坑是类型隐式转换：比如把 SYSDATETIME() 插入到 DATETIME 字段，会丢失精度且可能四舍五入出错（如 2024-05-20 14:30:45.1234567 存成 2024-05-20 14:30:45.123）。
- 建表时优先用
DATETIME2(3)或DATETIME2(7)，兼顾精度与存储（比DATETIME省 1 字节） - 跨库同步时注意：Oracle 的
SYSDATE精度只有秒，和SYSDATETIME()对不上 -
GETUTCDATE()和SYSUTCDATETIME()是对应 UTC 版本，别和本地时间混用
SQLite 没有 NOW() 函数？用 datetime('now') 就行
SQLite 不提供传统 SQL 的 NOW()，但内置字符串函数 datetime() 支持 'now' 字面量，效果一样。它返回 ISO8601 格式字符串（如 "2024-05-20 14:30:45"），不是原生日期类型——所有时间运算都靠字符串函数模拟。
这导致两个硬伤：不能直接和整数列比大小，也不能用标准 SQL 的 INTERVAL 加减。想算“30 分钟前”，得写 datetime('now', '-30 minutes')，而不是 now() - INTERVAL '30 minutes'。
- 需要精确到毫秒？加
'localtime'或'utc'修饰符没用，datetime('now')本身不支持毫秒 - 存时间建议用 INTEGER 存 Unix 时间戳（秒级），用
strftime('%s', 'now')获取，计算和索引都更高效 - 别信文档里说的 “
current_timestamp是关键字”——它只是个常量别名，实际仍走datetime('now')逻辑
时区、事务快照、类型精度——这三个点不提前对齐，查出来的时间看着对，用着就出问题。
