彻底搞懂数据库 NOW() 函数：语义差异、时区陷阱与索引坑

做数据库开发这些年，我见过太多同事在时间函数上栽跟头。明明就是一句SELECT NOW()，换一个数据库跑，结果可能差了好几个小时；同一个数据库里，两条语句间隔几秒执行，返回的时间戳居然一模一样。有人拿 NOW() 去写查询条件，结果索引压根没被用到；有人把 NOW() 写进默认值，备份恢复之后时间全线错位。今天咱就把 NOW() 函数彻底聊透：它到底返回的是什么语义、不同数据库实现有什么差异、跟CURRENT_TIMESTAMP、SYSDATE、GETDATE这些"近亲"之间是什么关系，以及实战里那些踩了才知道的坑。这篇内容面向所有写过 SQL 的开发者，不管你是天天跟 MySQL 打交道，还是在混合数据库环境里被各种时间函数搞得头大，应该都能找到点有用的东西。

1. 一个简单函数，三种"现在"：NOW() 的语义为什么没你想的那么简单

1.1 "现在"究竟指哪个瞬间

很多人以为NOW()就是"调用那一刻的当前时间"，但严格说起来，数据库压根没有统一的"那一刻"定义。不同数据库对"现在"的语义做了完全不同的选择：有的取语句开始执行的时刻，有的取整个事务开始的时刻，还有的取函数真正被调用到的时刻。这三个时间点在实际业务里能差出好几秒，甚至更长。

拿 PostgreSQL 举例，now()实际上是transaction_timestamp()的别名，它返回的是当前事务开始的时间戳。也就是说，你在一个事务里执行十条语句，分别调用十次now()，拿到的永远是同一个值。这个特性在长事务里特别容易让人困惑——你明明在一个事务里跑了一个耗时 20 秒的批量任务，结果每条 INSERT 记录的时间戳都一模一样。而clock_timestamp()才是真正意义上"实时时钟"，每调用一次都会重新读取系统时间。

MySQL 的做法又不一样。NOW()在一条语句里是常量，它取的是语句开始执行的时间点；但SYSDATE()取的是自身被调用时刻的系统时间。平时单条语句看不出区别，一旦放进存储过程、触发器或者执行很慢的大查询里，差异就出来了。这也是官方文档里特意警告不要轻易用SYSDATE()的原因之一。

1.2 返回类型和精度，两分钟说清

NOW()返回的并不总是同一个类型。同样是"当前时间"，MySQL 的NOW()返回的是DATETIME，不带时区信息；PostgreSQL 的now()返回的是TIMESTAMP WITH TIME ZONE（简称timestamptz），显示出来长什么样取决于你会话里的TimeZone设置；Oracle 压根没有NOW()，最常用的是返回DATE类型的SYSDATE。

精度方面更是参差不齐。MySQL 的NOW()默认只精确到秒，想拿更高精度得自己指定：NOW(3)是毫秒，NOW(6)是微秒。PostgreSQL 的now()直接给你微秒精度，不需要额外参数。SQL Server 的GETDATE()返回的是datetime类型，精度大约 3.33 毫秒，而SYSDATETIME()返回datetime2(7)，可以精确到 100 纳秒。

这里提醒一句：你看到的"当前时间"精度高不代表数据库存储时间列的精度也高。DATETIME不带毫秒、TIMESTAMP到微秒、datetime2纳秒级精度，这些完全是表结构的另一个维度，跟NOW()函数本身没有半毛钱关系。

2. 不同数据库里的 NOW()：同名函数，五套脾气

2.1 MySQL：默认精度只有秒，别忘 NOW(6)

MySQL 里NOW()和CURRENT_TIMESTAMP、CURRENT_TIMESTAMP()是等价别名，返回会话时区下的当前时间。最需要注意的一点是它默认只到秒。我之前排查过一个线上问题：业务要求记录订单创建时间精确到毫秒，开发用的却是默认的NOW()，导致同一秒内创建的上百个订单时间完全一样，排序全靠自增 ID 兜底。改成NOW(3)之后数据才恢复正常。

时区方面，MySQL 的NOW()跟随会话变量time_zone。也就是说，你在连接里执行SET time_zone = '+08:00'和SET time_zone = '+00:00'，拿到的NOW()能相差八个小时。更坑的是，如果表里用的是TIMESTAMP列，写入时 MySQL 会先把会话时区的值转成 UTC 存储，读出来再转回会话时区；而DATETIME列完全不转换，存什么就是什么。这种"一个函数配两种列类型"的组合拳，是时区事故的最高发源头。

2.2 PostgreSQL：事务开始时间戳，一锤定音

PostgreSQL 的now()返回的是带时区的timestamptz，但核心行为是"所在事务的开始时刻"。翻译成人话：事务一旦开始，now()就被锁死了，事务没提交之前你不管调用多少次，它都拒不更新。

这个设计在大多数场景下是合理的——它能让同一事务内的多条写入拥有统一的时间基准，保证数据一致性。但同样它也埋了雷，我见过一个定时任务脚本，一个事务里先处理了几万行旧数据，再插入一批新记录，结果新记录的时间戳全部被记成了事务开始的时间，比真实时间早了二十多分钟。事后排查半天才发现是now()的事务语义在作祟。如果你确实需要"每次调用都取当前时刻"，得用clock_timestamp()。

2.3 SQL Server 与 SQLite：没有 NOW() 却别有洞天

SQL Server 里压根没有NOW()这个函数。最常用的替代是GETDATE()（返回datetime）和SYSDATETIME()（返回高精度的datetime2(7)）。另外CURRENT_TIMESTAMP在 SQL Server 里作为GETDATE()的别名存在，这是 ANSI SQL 标准里定义的，所以它不加括号也能用。

SQLite 就更朴素了：没有NOW()函数，只有CURRENT_TIMESTAMP这几个关键字，而且它返回的是 UTC 时间，不是本地时间。你要是想拿本地时间，得写datetime('now', 'localtime')。很多从 MySQL 迁到 SQLite 的初学者在这里被坑过——拿到的"当前时间"总比预期少八个小时。

2.4 Oracle：SYSDATE 与 SYSTIMESTAMP 的替代逻辑

Oracle 用户别找NOW()了，它不存在。最基础的是SYSDATE，返回数据库服务器本地时区的DATE类型，只有秒级精度。想要更高精度和更完整的时区信息，用SYSTIMESTAMP，返回TIMESTAMP WITH TIME ZONE，纳秒级精度。

区别在于SYSDATE是基于数据库服务器的操作系统时间，跟你客户端会话所在的时区毫无关系；而CURRENT_DATE和CURRENT_TIMESTAMP基于你的会话时区。如果数据库服务器设的是 UTC，客户端在北京，那么SYSDATE和CURRENT_DATE的结果差八个小时是很正常的。

下面这张表把常见数据库的时间函数对照收一下，方便你收藏备用：

3. 和 CURRENT_TIMESTAMP、SYSDATE、GETDATE 掰扯清楚：别再靠猜选函数

3.1 标准 SQL 的正统：CURRENT_TIMESTAMP 到底要不要加括号

CURRENT_TIMESTAMP在 SQL 标准里是关键字，不是函数，所以标准写法是不带括号的。很多从 MySQL 入门的人习惯性写成CURRENT_TIMESTAMP()，在 MySQL 里因为做了兼容所以确实能跑，但换到 SQL Server 或者 SQLite 里，带括号的写法直接报错。这个差异让不少人在迁移脚本时一脸茫然。

从语义上讲，标准定义的CURRENT_TIMESTAMP是"SQL 语句开始执行的时刻"。但前面说了，PostgreSQL 把CURRENT_TIMESTAMP实现成了事务开始时刻，跟 SQL 标准有了细微出入。好在这种差异绝大多数业务根本感知不到，只有长事务、跨语句对比时间时才会暴露。

我的建议是：写可移植性要求高的 SQL 时，优先用不带括号的CURRENT_TIMESTAMP，它能同时在 MySQL、PostgreSQL、SQL Server、SQLite 里跑。只有当你明确需要某个数据库的特有行为（比如 PostgreSQL 的transaction_timestamp()语义）时，再换回NOW()也不迟。

3.2 SYSDATE、GETDATE 的隐藏差异：时区与精度不是唯一变量

SYSDATE在 Oracle 和 MySQL 里都存在，但含义完全不同。Oracle 的SYSDATE是数据库服务器的时间，跟会话时区无关；MySQL 的SYSDATE()则是"函数被调用的实时时刻"，跟NOW()的语句常量语义有本质区别。如果你在两套数据库之间写迁移脚本，千万别想当然地直接替换。

GETDATE()是 SQL Server 专属，很多人误以为它是CURRENT_TIMESTAMP的别名，反过来写也成立——实际上 SQL Server 文档里明确CURRENT_TIMESTAMP就是GETDATE()的 ANSI 别名。要注意GETDATE()返回的是服务器的本地时间，如果服务器时区配错了，所有埋点数据的时间都会跟着错。所以我会在巡检清单里加一条：检查数据库服务器操作系统时区，要比检查业务代码里的时区转换更优先。

再补一个容易忽略的点：存储过程和触发器里的时间函数。MySQL 官方文档指出，在存储函数或触发器中调用NOW()，它返回的是该函数或触发器开始执行的时间，而不是外层语句开始的时间。某些场景下这反而比SYSDATE()更可预测，至少它在一个子程序内是固定的。

4. 实战连环坑：时区、默认值、索引，每一个都能坑出血

4.1 时区不一致引发的"八小时偏移"

先看一个典型场景。应用部署在某云服务器上，操作系统时区是UTC，业务方在北京，要求看到北京时间。开发在 JDBC 连接串里加了serverTimezone=Asia/Shanghai，MySQL 那边NOW()返回的也是会话时区下的正确时间，一切看着正常。

但有一天 DBA 做数据归档，用另一个客户端连上库，连接默认走的还是服务器的 UTC 时区，结果SELECT NOW()显示的比北京时间少八个小时。真正出问题是在写入：TIMESTAMP列存储时会从会话时区转成 UTC，读出来再转回会话时区。如果应用连接和查询连接用的时区设置不一致，同一个字段的展示结果就会来回跳。

排查思路很简单，先统一三处时区：数据库服务器系统时区、MySQL 的全局time_zone变量、应用连接串里的会话时区。三处全部固定成同一个值，NOW()的返回值就稳定了。我个人习惯统一用+08:00这种带固定偏移量的写法，而不是Asia/Shanghai这种地区名，避免 MySQL 的时区表在部分精简安装里缺失导致报错。

4.2 默认值陷阱：DEFAULT NOW() 不是哪里都能写

MySQL 里给时间列设默认值时，不少新人会写DEFAULT NOW()，然后直接报语法错误。正确写法是DEFAULT CURRENT_TIMESTAMP。更早的版本里只有TIMESTAMP列能带默认当前时间，DATETIME列在 5.6.5 之前想都不用想。现在虽然支持了，但还要注意一列最多只能有一个CURRENT_TIMESTAMP作为默认值或ON UPDATE值，而且这俩限制在 MySQL 5.6 和 5.7 里的行为还有细微差别。

PostgreSQL 这边更常见的写法是DEFAULT now()，但别忘了它是事务开始时间。一批数据在同一个事务里通过存储过程分多次插入，所有行的时间戳都一样，这可能是"bug"也可能是"特性"，取决于你的业务需求。如果要求的是每行真实写入时刻，默认值建议用clock_timestamp()，或者干脆在应用层生成时间戳再传进去。

备份恢复场景更要命。逻辑备份导出、导入时，如果表依赖默认值生成时间，恢复出来的库里所有新记录的时间都会被重置为恢复那一刻，跟业务真实发生时间完全对不上。所以凡是承载业务审计语义的时间字段，我都建议在写入时显式传入时间，而不是依赖数据库默认值。

4.3 函数包裹列导致索引失效

WHERE created_at = NOW()这种写法，在 MySQL 里通常能正常走created_at上的索引，因为NOW()在语句里被当作常量处理，优化器可以把它固定下来然后做索引范围扫描。真正让索引失效的，是你为了"格式化对比"而把列包进函数里，比如WHERE DATE(created_at) = CURRENT_DATE。

一旦对列应用了函数，索引里存的原始值没法直接参与匹配，数据库只能全表扫一遍，每行算完函数之后才能判断。这个知识点老生常谈，但我见过的生产事故里，因为图省事把DATE(created_at)写进查询导致的慢查询，占比相当高。换成范围查询就好得多：

-- 推荐：直接用范围比较 WHERE created_at >= '2025-01-01' AND created_at < '2025-01-02';

PostgreSQL 里还有个进阶坑：now()是STABLE级别的函数，而索引表达式要求函数必须是IMMUTABLE，所以你不能直接拿now()建表达式索引。MySQL 的生成列也不允许使用NOW()这种不确定函数。这个限制不是数据库偷懒，而是逻辑上就没有意义——索引值如果每次算都不一样，那索引还有啥用？

5. 什么时候该绕过 NOW()？性能、确定性与替代方案

5.1 大批量插入时的时间统一问题

NOW()在单条语句里语义稳定，但跨语句它就未必了。同一事务里先执行一条耗时很长的查询，再执行一批 INSERT，数据库自动填的时间戳都是事务开始时刻，这在某些场景下会造成时间失真。反过来，如果你用的是SYSDATE()或clock_timestamp()，同一批数据可能因为执行时间横跨几秒而出现时间戳不连续。

更隐蔽的问题出在复制环境。基于语句的复制模式下，主库执行INSERT时生成的NOW()值，和从库回放时自己生成的NOW()值，很可能不一致——特别是从库延迟较大的时候。MySQL 对SYSDATE()在基于语句的复制中会直接标记为不安全，就是这个原因。解决思路有两个：一是把binlog_format调整为基于行的复制，让日志里直接保存计算后的实际值；二是对关键审计字段，统一在应用层获取一次时间，显式传给所有 INSERT 语句。

我把这个原则总结成一句话：凡是需要跨系统、跨主从保持一致的时间基准，一律别用数据库函数现场生成，直接用应用层传参。

5.2 函数确定性对索引、物化视图和缓存的影响

NOW()这类时间函数本质上是不确定的，每次执行结果都不同。不确定性函数带来的最大麻烦不是准确性问题，而是无法被缓存、无法被索引、无法被物化。

MySQL 的查询缓存（在 8.0 已移除）当年对包含不确定函数的查询一律不缓存，就是因为缓存一个随时过期的结果没有意义。PostgreSQL 的物化视图、分区裁剪策略里，如果表达式依赖now()，优化器很难提前裁剪分区——它不知道运行到那时候"现在"是哪一天。这也是为什么很多按天分区的表，写查询时宁可用应用程序先算出日期范围再传参，而不是在 SQL 里现算。

另外有个容易忽略的点：测试环境里为了让 SQL 可复现，我常建议用固定的时间参数代替NOW()。否则同样的查询在不同的时间点跑，结果永远对不上，单元测试和回归测试都难写。

5.3 我的日常选型建议

做了这么多年数据开发，我给自己定了一套时间函数的使用规矩，分享出来供参考：

• 表结构默认值：用CURRENT_TIMESTAMP（MySQL）或now()（PostgreSQL），适合"创建时间"这种不敏感字段。
• 业务关键时间：应用层生成ISO 8601格式带时区偏移的时间戳，显式写入，避免任何数据库函数参与。
• 查询过滤条件：优先用显式时间范围，避免对列套函数。
• 跨数据库迁移：统一用CURRENT_TIMESTAMP关键字，少用数据库方言函数。
• 精度敏感字段：MySQL 明确用NOW(3)或NOW(6)，别赌默认精度。
• 高并发排序：如果同一秒内记录多到影响排序稳定性，要么上微秒精度，要么用自增序列兜底。

这些规矩不是凭空想出来的，每一条背后都有对应的线上事故。我自己吃过最大的亏是 2038 年问题——MySQL 的TIMESTAMP类型范围只到 2038 年，当年建表时没在意，后来业务规划超过这个年限的数据都成了隐患。虽然这跟NOW()函数本身无关，但提醒各位：时间函数用得再熟，也不如一开始选对一个能承载未来业务范围的时间类型。真等到那天，别说NOW()了，整张表都得翻出来重建。

最后再补一句实操心得：排查时间相关问题时，别急着怀疑代码。先把数据库服务器时区、会话时区、连接串参数、列类型四样东西列出来对着看，八成问题都不用改代码就能定位。NOW()只是那把打开时间问题的钥匙，真正重要的，是你对整条时间链路的理解到底有多深。