记一次 MySQL timestamp 精度问题的排查 → 过程有点曲折

开心一刻

　　下午正准备出门，跟正刷着手机的老妈打个招呼

　　我：妈，今晚我跟朋友在外面吃，就不在家吃了

　　老妈拿着手机跟我说道：你看这叫朋友骗缅北去了，tm血都抽干了，多危险

　　我：那是他不行，你看要是吴京去了指定能跑回来

　　老妈：还吴京八经的，特么牛魔王去了都得耕地，唐三藏去了都得打出舍利，孙悟空去了都得演大马戏

　　我：那照你这么说，唐僧师徒取经走差地方了呗

　　老妈：那可没走错，他当年搁西安出发，他要是搁云南出发呀，上午到缅北，下午他就到西天

　　我：哈哈哈，那西游记就两级呗，那要是超人去了呢？

　　老妈：那超人去了，回来光剩超，人留那了

问题复现

　　我简化下业务与项目

　　数据库： MySQL 8.0.25 

　　基于 spring-boot 2.2.10.RELEASE 搭建 demo ：spring-boot-jpa-demo

　　表： tbl_user 

　　测试代码：

/**
 * @description: xxx描述
 * @author: 博客园@青石路
 * @date: 2024/1/9 21:42
 */
@RunWith(SpringRunner.class)
@SpringBootTest
@Slf4j
public class UserTest {

    @Resource
    private UserRepository userRepository;

    @Test
    public void get() {
        DateTimeFormatter dft = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS");
        Timestamp lastModifiedTime  = Timestamp.valueOf(LocalDateTime.parse("2024-01-11 09:33:26.643", dft));

        // 1.先保存一个user
        User user = new User();
        user.setUserName("zhangsan");
        user.setPassword("zhangsan");
        user.setBirthday(LocalDate.now().minusYears(25));
        user.setLastModifiedTime(lastModifiedTime);
        log.info("user.lastModifiedTime = {}", user.getLastModifiedTime());
        userRepository.save(user);
        log.info("user 保存成功，userId = {}", user.getUserId());

        // 2.然后再根据id查询这个user
        Optional<User> userOptional = userRepository.findById(user.getUserId());
        if (userOptional.isPresent()) {
            log.info("从数据库查询到的user，user.lastModifiedTime = {}", userOptional.get().getLastModifiedTime());
        }
    }
}

　　这么清晰的代码，大家都能看懂吧？

　　我们来看下日志输出

　　保存的时候， lastModifiedTime 的值是 2024-01-11 09:33:26.643 ，从数据库查询得到的却是： 2024-01-11 09:33:27.0 

　　是不是被震惊到了？

曲折排查

　　先确认下 MySQL 表中存的值是多少

　　数据库表中的值就是 2024-01-11 09:33:27 ，此刻我只想来一句：卧槽！

　　这说明数据入库有问题，而不是读取有问题

　　我们来梳理下数据入库经历了哪些环节

　　那问题肯定出在 Spring Data JPA 至 mysql-connector-java 之间

　　 MySQL 肯定是没问题的！

　　源码跟踪

　　既然问题出在 Spring Data JPA 与 mysql-connector-java 之间，那么我们就直接来个一穿到底，翻了它的源码老底

　　大家请坐好，我要开始装逼了

　　 JPA 用的少，一时还不知道从哪里开始去跟源码，但不要慌，楼主有 葵花宝典 ：杂谈篇之我是怎么读源码的，授人以渔

　　断点追踪源码，一时用一时爽，一直用一直爽

　　直接在 userRepository.save(user) 前面打个断点，然后一步一步往下跟，我就不细跟了，我只在容易跟丢的地方指出来，给你们合适的方向

　　当断点到 SessionImpl#firePersist 方法时

　　我们应该去跟 PersistEventListener::onPersist 了，一路跟下去，会来到 AbstractSaveEventListener#performSaveOrReplicate 方法

　　里面有如下代码

　　添加的 Action 的实际类型是： EntityIdentityInsertAction 

　　这里涉及到了 hibernate 的 事件机制 ，简单来说就是 EntityIdentityInsertAction 的 execute 方法会被调用

　　所以我们继续从 EntityIdentityInsertAction#execute 跟，会来到 GetGeneratedKeysDelegate#executeAndExtract 

　　重点来了，大家打起精神

　　继续跟进 session.getJdbcCoordinator().getResultSetReturn().executeUpdate( insert ) 的 executeUpdate 

　　它长这样

　　如果不是断点跟的话

　　你知道接下来跟谁吗？

　　当然，非常熟悉源码的人（比如我），肯定知道跟谁

　　但是用了断点，大家都知道跟谁了

　　继续往下跟，当我们来到 ClientPreparedStatement#executeInternal 时，真相已经揭晓

　　此时已经来到了 mysql-connector-java ，发送给 MySQL Server 的 SQL 是：

　　 last_modified_time 精度没丢！

　　那问题出在哪？

　　还能出在哪， MySQL 呗！

　　说好的 MySQL 没问题的了？

　　MySQL 时间精度

　　用排除法，排的只剩 MySQL 了，直接执行 SQL 试试

　　哦豁，敢情前面的源码分析全白分析了，我此刻的心情你们懂吗

　　这必须得找 MySQL 要个说法，真是太狗了

　　我们去 MySQL 官方文档找找看（注意参考手册版本要和我们使用的 MySQL 版本一致）

　　大家不要通篇去读，那样太费时间，直接 search 用起来

　　The DATE, DATETIME, and TIMESTAMP Types 有这么一段比较关键

　　我给大家翻译一下

　　继续看 Fractional Seconds in Time Values，内容不多，大家可以通篇读完

　　 MySQL 的 TIME ， DATETIME 和 TIMESTAMP 都支持微妙级别（6位数）的小数位

　　精度直接在括号中指定，例如： CREATE TABLE t1 (t TIME(3), dt DATETIME(6)) 

　　小数位的范围是 0 到 6。0 表示没有小数部分，如果小数位缺省，则默认是0（SQL规范规定的默认是 6，MySQL8 默认值取 0 是为了兼容 MySQL 以前的版本）

　　当插入带有小数部分的 TIME ， DATETIME 或 TIMESTAMP 值到相同类型的列时，如果值的小数位与精度不匹配时，会进行四舍五入

　　四舍五入的判断位置是精度的后一位，比如精度是 0，则看值的第 1 位小数，来决定是舍还是入，如果精度是 2，则看值的第 3 位小数

　　简单来说：值的精度大于列类型的精度，就会存在四舍五入，否则值是多少就存多少

　　当发生四舍五入时，既不会告警也不会报错，因为这就是 SQL 规范

　　那如果我不想要四舍五入了，有没有什么办法？

　　 MySQL 也给出了支持，就是启用 SQL mode ：TIME_TRUNCATE_FRACTIONAL

　　启用之后，当值的精度大于列类型的精度时，就是直接按列类型的精度截取，而不是四舍五入

　　那这么看下来，不是 MySQL 的锅呀， MySQL 表示这锅我不背

　　那是谁的锅？

　　只能说是开发人员的锅，为什么不按 MySQL 使用说明书使用？

　　我要强调的是，产生这次问题的代码不是我写的，我写的代码怎么可能有 bug 

总结

　　1、 源码 debug 堆栈

　　2、MySQL 时间精度

　　　　 MySQL 的 TIME ， DATETIME 和 TIMESTAMP 类型都支持微妙级别（6位数）的精度

　　　　默认情况下会四舍五入，若想直接截断，则需要开启 SQL mode ： TIME_TRUNCATE_FRACTIONAL 

　　3、规范

　　　　阿里巴巴的开发手册中明确指出不能用： java.sql.Timestamp 

　　　　另外很多公司的 MySQL 开发规范会强调：没有特殊要求，时间类型用 datetime 

　　　　主要出于两点考虑：1、 datetime 可用于分区，而 timestamp 不行，2、 timestamp 的范围只到 2038-01-19 03:14:07.499999 

　　　　有的开发小伙伴可能会问：如果到了 2038-01-19 03:14:07.499999 之后， timestamp 该怎么办？

　　　　我只能说：小伙子你想的太远了， 2038 跟我们有什么关系，影响我们送外卖吗？

补充

　　关于上面讲到的 timestamp 不能分区，进行一下补充（感谢 @xiaohuazi 指正）

　　它能分区，但是和  DATE  和 DATETIME  有一丢丢区别

　　MySQL 5.7 说明如下

　　MySQL 8.0 说明如下

　　 timestamp 类型的列只能基于 UNIX_TIMESTAMP 函数进行分区