正文

 /**
 * The maximum supported {@code LocalTime}, '23:59:59.999999999'.
 * This is the time just before midnight at the end of the day.
 */
 public static final LocalTime MAX;
 /**
  * The maximum supported {@code LocalDateTime}, '+999999999-12-31T23:59:59.999999999'.
  * This is the local date-time just before midnight at the end of the maximum date.
  * This combines {@link LocalDate#MAX} and {@link LocalTime#MAX}.
  * This could be used by an application as a "far future" date-time.
  */
 public static final LocalDateTime MAX = LocalDateTime.of(LocalDate.MAX, LocalTime.MAX);

我們可以看到 LocalTime 和 LocalDateTime 的精度是可以去到 9 也就是達(dá)到納秒

但是為什么我們經(jīng)常打印出來的時(shí)候往往只有小數(shù)點(diǎn)后三位、也就是毫秒

 LocalDateTime now = LocalDateTime.now();
 System.out.println(now);

調(diào)用System的currentTimeMillis

我們看到源碼最終還是調(diào)用了 System的currentTimeMillis

 @Override
 public long millis() {
     return System.currentTimeMillis();
 }
 @Override
 public Instant instant() {
     return Instant.ofEpochMilli(millis());
 }

最近測試環(huán)境中出現(xiàn)了個(gè)時(shí)間精度的問題、計(jì)算某個(gè)流程所花費(fèi)的時(shí)間的時(shí)候得出了負(fù)數(shù)、因?yàn)榇鎯?chǔ)該字段的類型設(shè)置了無符號(hào)、導(dǎo)致插入的時(shí)候報(bào)錯(cuò)、超出該類型的值的范圍。

當(dāng)時(shí)的第一反應(yīng)是流程對(duì)應(yīng)的步驟是不是分別在不同的容器中執(zhí)行、容器之間是否存在時(shí)間差。

后面排查所有的步驟均執(zhí)行在同一個(gè)容器中、日志打印的時(shí)間和sql插入的值均沒啥差異。select 出來的值沒有打印出來。

后面看到其中日志打印insert 的值的秒比數(shù)據(jù)庫中的秒要少一秒。然后發(fā)覺沒有設(shè)置 dateTime 的精度

這個(gè)其實(shí)是錄入表的同事遺漏了、原本設(shè)計(jì)表結(jié)構(gòu)是有6位精度的(規(guī)范要求)。

后面補(bǔ)上精度、順手將無符號(hào)也去掉

Mysql 中的 dateTime 精度默認(rèn)為 0 、最大可以去到 6。

如果入?yún)⒌木却笥?dateTime 的精度、那么將會(huì)進(jìn)行四舍五入。

小結(jié)

插入的時(shí)候、如果輸入的精度比聲明的精度高、那么則會(huì)對(duì)其進(jìn)行四舍五入

查詢

值得注意的是、LocalTime ｜ LocalDateTime 的 MAX 是 9位 的、如果

 drop table mqst1;
 create table mqst1
 (
     id         int      null,
     createtime datetime(0) null
 );
 INSERT INTO test_schema.mqst1 (id, createtime) VALUES (1, '2021-10-01 21:08:08.123');
 INSERT INTO test_schema.mqst1 (id, createtime) VALUES (1, '2021-10-01 23:59:59.567');
 INSERT INTO test_schema.mqst1 (id, createtime) VALUES (2, '2021-10-02 00:00:00.000');
 select *
 from mqst1
 where createtime >= '2021-10-01 00:00:00'  and createtime <= '2021-10-01 23:59:59.999999';
 select *
 from mqst1
 where createtime >= '2021-10-01 00:00:00' and createtime <= '2021-10-01 23:59:59.9999995';

第二條的查詢就最后的參數(shù)比第一條的時(shí)間多了一個(gè) 5

首先看插入結(jié)果

那么第一條的查詢結(jié)果是只有一條

第二條的查詢結(jié)果卻是 3 條。

因?yàn)?mysql 將字符串轉(zhuǎn)換成 dateTime 的時(shí)候使用的是 6 位的精度、超過六位的才會(huì)四舍五入、所以導(dǎo)致第二條的查詢條件變?yōu)?10-02 00:00:00

我們將 dateTime 的精度改為 2

 createtime datetime(2) null

那么第一條的查詢結(jié)果為兩條

而第二條的查詢結(jié)果還是為三條

即使將精度改為6也是這樣的結(jié)果

總結(jié)

對(duì)于查詢而已、mysql 會(huì)對(duì) string 的轉(zhuǎn)換如果超出 6 位 多出的會(huì)進(jìn)行四舍五入、然后才會(huì)去表中進(jìn)行比較

事實(shí)上對(duì)于大多數(shù)場景而已、Java 提供的毫秒級(jí)別的時(shí)間以及能滿足大多數(shù)場景了、對(duì)應(yīng)到 db 存儲(chǔ)時(shí)間到精度、

建議直接 6 會(huì)比較省心點(diǎn)吧、跟 Mysql 做字符串轉(zhuǎn)換 dateTime 的時(shí)候一樣。

查詢到時(shí)候需要注意的是如果上限被包含進(jìn)去、需要考慮精度是否超過 Mysql 的最大精度、如果超過了則可能你會(huì)被舍入

 System.out.println(LocalDateTime.of(LocalDate.now(), LocalTime.MAX).withNano(999999000));

以上就是Mysql DateTime查詢問題解析的詳細(xì)內(nèi)容，更多關(guān)于Mysql DateTime的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論