今天寫(xiě)代碼突發(fā)一個(gè)詭異的 bug，代碼邏輯大概如下。

1. 新增退款單記錄
boolean save = shopOrderRefundService.save(shopOrderRefundAdd);

// 2. 調(diào)用京東退款
MiniappRefundResponse response = jdOrderOpenApiService.miniappRefund(...);
if (response.isSuccess()) {
    shopOrderRefundAdd.setStatus(ShopOrderRefundStatusEnum.SYNC_FAIL.getDatabaseCode());
    boolean update = shopOrderRefundService.updateByIdAndStatus(shopOrderRefundAdd);
    //返回失敗
    ...
}

// 3. 更新退款單狀態(tài)調(diào)用成功
shopOrderRefundAdd.setStatus(ShopOrderRefundStatusEnum.JD1001.getDatabaseCode());
boolean update = shopOrderRefundService.updateByIdAndStatus(shopOrderRefundAdd);
...

先生成退款單入庫(kù)，再調(diào)京東接口，根據(jù)接口返回值再修改退款單狀態(tài)。
問(wèn)題是第三步修改的時(shí)候，有時(shí)成功有時(shí)失敗。

本地跑了下，跟事物沒(méi)關(guān)系。

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]

拉同事過(guò)來(lái)一起看，發(fā)現(xiàn)修改的代碼有問(wèn)題。

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 代碼的時(shí)候忘把時(shí)間范圍去掉，用單號(hào)查就沒(méi)問(wèn)題了。
但就算有時(shí)間范圍，創(chuàng)建的時(shí)候肯定在修改前，為什么還是查不到呢？
又跑了幾遍發(fā)現(xiàn)時(shí)間插入的問(wèn)題。

注意看時(shí)間的毫秒，如果傳入的SQL帶毫秒，MySQL在入庫(kù)的時(shí)候自動(dòng)四舍五入了，這導(dǎo)致本來(lái)是 07.599 秒的數(shù)據(jù)變成了 08 秒。
但也不對(duì)，后面就算是 07.699，如果轉(zhuǎn)成 08 也能查到。
我把更新 SQL 的查詢(xún)部分單獨(dú)拎出來(lái)看。
假設(shè)數(shù)據(jù)庫(kù)里有只有這條數(shù)據(jù)。 order_no 是主鍵，create_at 有索引，create_at 是 datetime 類(lèi)型，不帶毫秒。

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 能查到數(shù)據(jù)？
答案是前兩個(gè)查不到，后三個(gè)查得到。

這是查看 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 很長(zhǎng)我不貼代碼了。通過(guò) Trace 可以看到 MySQL 分析器、優(yōu)化器、執(zhí)行器操作邏輯 。

這里面關(guān)于時(shí)間的坑很多，一一說(shuō)。

第一個(gè)為什么查不到？

優(yōu)化器先通過(guò) order_no 查詢(xún)到這條數(shù)據(jù)，再在優(yōu)化器中直接比較 "condition_value": false，因?yàn)?查出來(lái) create_at 是 2025-01-15 21:56:08 != 2025-01-15 21:56:07.974。

優(yōu)化器能識(shí)別毫秒，插入時(shí)候的四舍五入是執(zhí)行器入庫(kù)時(shí)候轉(zhuǎn)的。優(yōu)化器和執(zhí)行器在必要的時(shí)候都會(huì)四舍五入，但在這種直接比較的場(chǎng)景沒(méi)有轉(zhuǎn)。

第二個(gè)為什么查不到？

優(yōu)化器將這個(gè)范圍查詢(xún)執(zhí)行做成了 "'2025-01-15 21:56:07' < create_at < '2025-01-15 21:56:08'"，自然就查不到了，<= 才查得到。
為了驗(yàn)證我試了各種范圍 SQL，發(fā)現(xiàn)雖然優(yōu)化器做了四舍五入，但在范圍查詢(xún)的時(shí)候，< 和 <=，> 和 >=，也根據(jù)毫秒做了區(qū)分。

第三個(gè)、第四個(gè)為什么查得到？

分析器和優(yōu)化器把第三個(gè) SQL 優(yōu)化成了第四個(gè) SQL，由于是 = 查詢(xún)，優(yōu)化器和執(zhí)行器都做了四舍五入成了 08 秒，所以查得到。

第五個(gè)直接走 id 查詢(xún)自然查的出來(lái)。

以上是我的探索過(guò)程，很早前聽(tīng)過(guò) MySQL DATETIME 有坑，我這就是個(gè)真實(shí)的案例了。
其實(shí)吧應(yīng)該算自己對(duì)最底層了解的不夠深刻，分析器、優(yōu)化器、執(zhí)行器的代碼必然是非常復(fù)雜的，都是在踩坑中學(xué)習(xí)。
所以好一點(diǎn)的處理方式，要么換成時(shí)間戳，要么帶毫秒，要么用字符串，根據(jù)業(yè)務(wù)選擇吧。

到此這篇關(guān)于Mysql DATETIME 毫秒坑的解決的文章就介紹到這了,更多相關(guān)Mysql DATETIME 毫秒坑內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論