Mysql DATETIME 毫秒坑的解决

 更新时间:2025年01月18日 11:34:19   作者:jianzhangg  
本文主要介绍了Mysql DATETIME 毫秒坑的解决,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧

今天写代码突发一个诡异的 bug,代码逻辑大概如下。

1. 新增退款单记录
boolean save = shopOrderRefundService.save(shopOrderRefundAdd);

// 2. 调用京东退款
MiniappRefundResponse response = jdOrderOpenApiService.miniappRefund(...);
if (response.isSuccess()) {
    shopOrderRefundAdd.setStatus(ShopOrderRefundStatusEnum.SYNC_FAIL.getDatabaseCode());
    boolean update = shopOrderRefundService.updateByIdAndStatus(shopOrderRefundAdd);
    //返回失败
    ...
}

// 3. 更新退款单状态调用成功
shopOrderRefundAdd.setStatus(ShopOrderRefundStatusEnum.JD1001.getDatabaseCode());
boolean update = shopOrderRefundService.updateByIdAndStatus(shopOrderRefundAdd);
...

先生成退款单入库,再调京东接口,根据接口返回值再修改退款单状态。
问题是第三步修改的时候,有时成功有时失败。

本地跑了下,跟事物没关系。

Creating a new SqlSession
SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@af21da9] was not registered for synchronization because synchronization is not active
JDBC Connection [org.apache.shardingsphere.driver.jdbc.core.connection.ShardingSphereConnection@546d31d3] will not be managed by Spring
Closing non transactional SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@af21da9]

拉同事过来一起看,发现修改的代码有问题。

public boolean updateByIdAndStatus(ShopOrderRefund shopOrderRefund, Integer status) {
    DateTime date = DateUtil.date();
    return update(shopOrderRefund,new LambdaUpdateWrapper<ShopOrderRefund>()
            .eq(ShopOrderRefund::getOrderNo,shopOrderRefund.getOrderNo())
            .eq(ShopOrderRefund::getStatus,status)
            .between(ShopOrderRefund::getCreateAt, DateUtil.offsetMonth(date, -2), date)
    );
}

copy 代码的时候忘把时间范围去掉,用单号查就没问题了。
但就算有时间范围,创建的时候肯定在修改前,为什么还是查不到呢?
又跑了几遍发现时间插入的问题。

注意看时间的毫秒,如果传入的SQL带毫秒,MySQL在入库的时候自动四舍五入了,这导致本来是 07.599 秒的数据变成了 08 秒。
但也不对,后面就算是 07.699,如果转成 08 也能查到。
我把更新 SQL 的查询部分单独拎出来看。
假设数据库里有只有这条数据。 order_no 是主键,create_at 有索引,create_at 是 datetime 类型,不带毫秒。

select order_no, create_at
from shop_order_refund_202501
where
    order_no = 'SR20250115215607789061'
  and
    create_at BETWEEN '2025-01-15 21:56:07.974' AND '2025-01-15 21:56:07.974';
select order_no, create_at
from shop_order_refund_202501
where
    create_at BETWEEN '2025-01-15 21:56:07.274' AND '2025-01-15 21:56:07.974';
select order_no, create_at
from shop_order_refund_202501
where
    create_at BETWEEN '2025-01-15 21:56:07.974' AND '2025-01-15 21:56:07.974';
select order_no, create_at
from shop_order_refund_202501
where create_at = '2025-01-15 21:56:07.974' ;
select order_no, create_at
from shop_order_refund_202501
where
    order_no = 'SR20250115215607789061';

猜猜哪些 SQL 能查到数据?
答案是前两个查不到,后三个查得到。

这是查看 MySQL Server 层的 Trace 的 SQL。

SET optimizer_trace = "enabled=on";
select order_no, create_at
from shop_order_refund_202501
where
    order_no = 'SR20250115215607789061'
  and
    create_at BETWEEN '2025-01-15 21:56:07.974' AND '2025-01-15 21:56:07.974';
SELECT *
FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE;
SET optimizer_trace = "enabled=off";
SHOW SESSION VARIABLES LIKE 'optimizer_trace%';
SHOW GLOBAL VARIABLES LIKE 'optimizer_trace%';

Trace 很长我不贴代码了。通过 Trace 可以看到 MySQL 分析器、优化器、执行器操作逻辑 。

这里面关于时间的坑很多,一一说。

第一个为什么查不到?

优化器先通过 order_no 查询到这条数据,再在优化器中直接比较 "condition_value": false,因为 查出来 create_at 是 2025-01-15 21:56:08 != 2025-01-15 21:56:07.974。

优化器能识别毫秒,插入时候的四舍五入是执行器入库时候转的。优化器和执行器在必要的时候都会四舍五入,但在这种直接比较的场景没有转。

第二个为什么查不到?

优化器将这个范围查询执行做成了 "'2025-01-15 21:56:07' < create_at < '2025-01-15 21:56:08'",自然就查不到了,<= 才查得到。
为了验证我试了各种范围 SQL,发现虽然优化器做了四舍五入,但在范围查询的时候,< 和 <=,> 和 >=,也根据毫秒做了区分。

第三个、第四个为什么查得到?

分析器和优化器把第三个 SQL 优化成了第四个 SQL,由于是 = 查询,优化器和执行器都做了四舍五入成了 08 秒,所以查得到。

第五个直接走 id 查询自然查的出来。

以上是我的探索过程,很早前听过 MySQL DATETIME 有坑,我这就是个真实的案例了。
其实吧应该算自己对最底层了解的不够深刻,分析器、优化器、执行器的代码必然是非常复杂的,都是在踩坑中学习。
所以好一点的处理方式,要么换成时间戳,要么带毫秒,要么用字符串,根据业务选择吧。

到此这篇关于Mysql DATETIME 毫秒坑的解决的文章就介绍到这了,更多相关Mysql DATETIME 毫秒坑内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • 解析远程连接管理其他机器上的MYSQL数据库

    解析远程连接管理其他机器上的MYSQL数据库

    本篇文章是对远程连接管理其他机器上的MYSQL数据库进行了详细的分析介绍,需要的朋友参考下
    2013-06-06
  • MySQL如何支撑起亿级流量

    MySQL如何支撑起亿级流量

    当每天新增数据上亿级的时候,单表数据量在百万级别,数据库服务器的高峰期写入压力、查询压力在都很高的时候,该如何让MySQL顺利支撑起来呢?本片文章将教给你详细的方案
    2021-09-09
  • mysql如何按字段查询重复的数据

    mysql如何按字段查询重复的数据

    这篇文章主要介绍了mysql如何按字段查询重复的数据问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-05-05
  • MySQL修改时间添加时间自动更新的两种方法

    MySQL修改时间添加时间自动更新的两种方法

    这篇文章主要介绍了MySQL修改时间添加时间自动更新的两种方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2023-09-09
  • Mysql Explain命令的使用与分析

    Mysql Explain命令的使用与分析

    今天小编就为大家分享一篇关于Mysql Explain命令的使用与分析,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
    2019-03-03
  • mysql处理海量数据时的一些优化查询速度方法

    mysql处理海量数据时的一些优化查询速度方法

    最近一段时间由于工作需要,开始关注针对Mysql数据库的select查询语句的相关优化方法,需要的朋友可以参考下
    2017-04-04
  • MySQL如何添加数据insert命令

    MySQL如何添加数据insert命令

    这篇文章主要介绍了MySQL如何添加数据insert命令问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2023-11-11
  • MySQL数据表使用的SQL语句整理

    MySQL数据表使用的SQL语句整理

    这篇文章主要介绍了MySQL数据表使用的SQL语句整理,文章基于MySQL的相关资料展开举例说明,具有一定的参考价值,需要的小伙伴可以参考一下
    2022-05-05
  • Mysql慢查询操作梳理总结

    Mysql慢查询操作梳理总结

    下面小编就为大家带来一篇Mysql慢查询操作梳理总结。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2017-03-03
  • Mysql模糊查询优化方法及测试详细讲解

    Mysql模糊查询优化方法及测试详细讲解

    这篇文章主要介绍了Mysql模糊查询优化方法及测试,在MySQL中支持模糊匹配的方法有很多,且各有各的优点,感兴趣想要详细了解可以参考下文
    2023-05-05

最新评论