mysql 时间精度问题

文章讨论了在MySQL数据库中,从5.6.4版本开始datetime类型的存储精度变化,如何影响到时间戳的处理,特别是在成本核算中的时间精确性。作者提醒在系统设计时要考虑这种变化,以适应可能的特定场景需求。
摘要由CSDN通过智能技术生成

timestamp到2038年,还有14年时间,一个系统如果能活到那一刻也是相当不错了。
这里先看一下个datetime的问题,下面的插入数据的时间戳是2024-03-06 21:20:50.839

INSERT INTO psi_io_balance ( id, as_id, bill_date, order_id, busi_type, direction, customer_id, ca_name, warehouse_id, stock_id, out_count, out_unit_cost, out_cost, final_count, final_unit_cost, final_cost, create_time, sn ) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )
==> Parameters: f0ad530bcd234a57bf11282e7900c0fe(String), 7(Integer), 2024-01-09 00:00:00.0(Timestamp), XSCKD202401090001(String), 03(String), 02(String), 557511(Integer), 工作室(String), 43ebf6d3ed024d738b3c788aea27ec1f(String), 538(Integer), 1(BigDecimal), 0.01000000(BigDecimal), 0.01(BigDecimal), 9.00000000(BigDecimal), 0.01000000(BigDecimal), 0.09(BigDecimal), 2024-03-06 21:20:50.839(Timestamp), 0(Integer)

因为系统设计,你可以任意选择时间插入,插入后将实时进行成本核算,于是就发生了向后面的数据作用。下面的create_time 应该大于2024-03-06 21:20:50.839,但因为数据库字段为datetime,因此自身也被查询数来了,可以看到2024-03-06 21:20:51 这个字段到秒,后面的毫秒被丢失

SELECT id,as_id,bill_date,order_id,busi_type,direction,vendor_id,customer_id,ca_name,warehouse_id,stock_id,in_count,in_unit_cost,in_cost,out_count,out_unit_cost,out_cost,final_count,final_unit_cost,final_cost,residue_count,end_flag,update_time,create_time,version,sn FROM psi_io_balance WHERE (bill_date = ? AND create_time > ? AND as_id = ? AND stock_id = ? AND warehouse_id = ?)
==> Parameters: 2024-01-09 00:00:00.0(Timestamp), 2024-03-06 21:20:50.839(Timestamp), 7(Integer), 538(Integer), 43ebf6d3ed024d738b3c788aea27ec1f(String)
<==    Columns: id, as_id, bill_date, order_id, busi_type, direction, vendor_id, customer_id, ca_name, warehouse_id, stock_id, in_count, in_unit_cost, in_cost, out_count, out_unit_cost, out_cost, final_count, final_unit_cost, final_cost, residue_count, end_flag, update_time, create_time, version, sn
<==        Row: f0ad530bcd234a57bf11282e7900c0fe, 7, 2024-01-09, XSCKD202401090001, 03, 02, null, 557511, 工作室, 43ebf6d3ed024d738b3c788aea27ec1f, 538, 0E-8, 0E-8, 0.00, 1.00000000, 0.01000000, 0.01, 9.00000000, 0.01000000, 0.09, 0E-8, 0, null, 2024-03-06 21:20:51, null, 0

mysql 5.6.4 之前数据库是会把datetime类型秒后面的精度丢掉,5.6.4之后的版本是会保留这个精度
因此需要修改数据库表

ALTER TABLE `psi`.`psi_io_balance` 
MODIFY COLUMN `create_time` datetime(3) NOT NULL COMMENT '创建时间' AFTER `update_time`;

这样查看数据库,字段就到毫秒了。一般可能用不到,但特定场景时间精确起到了关键作用
1

  • 3
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

warrah

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值