PostgreSQL时间异常：执行SELECT NOW()返回会话启动时间而非当前时间
2026-9-24
GCP Cloud SQL
SELECT NOW()返回会话启动时间问题排查解决步骤 1. 确认数据库引擎及时间函数默认行为
不同GCP托管数据库的时间函数逻辑存在原生差异，先执行对应验证：
- PostgreSQL：
NOW()/CURRENT_TIMESTAMP默认返回事务启动时间，而非语句执行的实时时间。需要获取当前实际时间请改用clock_timestamp()函数 - MySQL：
NOW()/CURRENT_TIMESTAMP默认返回语句执行开始时间，仅SYSDATE()返回函数执行的实时时间。如果NOW()返回会话启动时间，基本和长事务配置相关 - SQL Server：
GETDATE()默认返回实时时间，不存在返回会话启动时间的原生逻辑，需排查自定义配置
2. 检查会话事务提交配置
Dbeaver默认关闭新连接的自动提交，GCP控制台查询窗口部分场景也会默认开启长事务，这是该问题最高发的原因：
- 执行对应命令查看自动提交状态：
- MySQL：
SELECT @@autocommit;，返回0代表自动提交关闭 - PostgreSQL：
SHOW default_transaction_read_only;配合SELECT txid_current();确认是否存在长事务
- MySQL：
- 如果自动提交为关闭状态，你打开连接后的第一个查询会启动长事务，后续所有
NOW()调用都会返回这个事务的启动时间。手动执行COMMIT;结束当前事务后再次执行SELECT NOW();即可验证 - Dbeaver端可在「连接设置」-「编辑连接」-「驱动属性」中开启自动提交，避免默认启动长事务
3. 校验时区配置
确认实例全局时区与会话时区是否匹配，异常的时区配置也可能导致时间显示不符合预期：
- 执行对应命令查看时区配置：
- MySQL：
SELECT @@global.time_zone, @@session.time_zone; - PostgreSQL：
SHOW timezone;
- MySQL：
- 若会话时区被强制设置为非预期值，可执行
SET TIME ZONE '你需要的时区标识';临时修改后验证
4. 排查自定义时间覆盖逻辑
检查是否有自定义配置强制固定了时间返回值：
- Dbeaver端查看「连接设置」-「初始化脚本」，确认没有手动设置时间变量的逻辑
- GCP Cloud SQL端检查用户登录触发器、实例自定义参数，确认没有覆盖
NOW()返回值的配置
效果验证
完成调整后，间隔10秒两次执行SELECT NOW();，如果两次返回的时间差和实际等待时间一致，说明问题已修复。
内容的提问来源于stack exchange，提问作者Techno CRAT
相关产品推荐
相关产品推荐
