You need to enable JavaScript to run this app. 字段与行尾纳秒/微秒时间戳存储结果不一致问题咨询
优惠活动
大模型
产品
解决方案
定价
更多

字段与行尾纳秒/微秒时间戳存储结果不一致问题咨询

这个问题的核心是时序数据库对主键时间戳列、自定义TIMESTAMP类型字段的默认输入时间单位配置不一致,结合行协议的写入规则,两类字段的解析逻辑不同:

前提说明

  1. 你使用行协议写入时,行末尾不带键的数值对应建表语句中timestamp(timestamp)指定的主键时间戳列,也就是你定义的timestamp字段;带ts=前缀的是你自定义的普通TIMESTAMP字段。
  2. 你使用的数据库默认配置为:主键时间戳列的输入单位为纳秒,自定义TIMESTAMP字段的输入单位为微秒。

纳秒写入场景结果差异原因

  • 主键时间戳列timestamp收到的输入为纳秒格式的1626745200000000000,符合默认单位要求,换算后得到2021-07-22T01:40:00.000000Z,结果正确。
  • 自定义字段ts收到的输入为纳秒格式的1626652800000000000,被数据库按默认微秒单位解析,数值被多除以1000倍,换算后得到5万多年的异常结果,和你观测的错误一致。

微秒写入场景结果差异原因

  • 自定义字段ts收到的输入为微秒格式的1626652800000000,符合默认单位要求,换算后得到2021-07-19T00:00:00.000000Z,结果正确。
  • 主键时间戳列timestamp收到的输入为微秒格式的1626745200000000,被数据库按默认纳秒单位解析,数值被少除以1000倍,换算后仅为1970年1月1日加18天左右的结果,和你观测的错误一致。

解决方案

写入时统一指定全局时间单位参数,或者将两类TIMESTAMP字段的默认解析单位调整为相同值即可解决该问题。

内容的提问来源于stack exchange,提问作者Vlad Ilyushchenko

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.10.10 22:33:02