毫秒存储MySql引起的噩梦之旅

一个调试之旅:

当我第一次看到这个问题时，因为我自己没有写代码，所以我猜想代码一定写错了，并且有一个分支代码导致部分数据正确，而部分数据则是错误的. 不正确该代码根据业务逻辑进行定位，简化后的代码如下:

@Service
public class CouponServiceImpl implements CouponService{
.....
public void addCoupon(){
.........
coupon.setEndDate(lastMoment(getEndTime(3, new Date(), 7)));
couponDao.create(coupon);
}
public static Date lastMoment(Date date) {
Calendar cl = Calendar.getInstance();
cl.setTime(date);
cl.set(Calendar.HOUR_OF_DAY, 23);
cl.set(Calendar.MINUTE, 59);
cl.set(Calendar.SECOND, 59);
return cl.getTime();
}
}

仔细查看代码，没有分支逻辑，只有在此设置结束时间的业务代码. 似乎代码本身没有错.

调试之路二:

代码中没有明显的错误，可能不是jdk问题，项目使用jdk1.6. 根据这个想法mysql 获取当前毫秒，百度发现了jdk1.6的一些错误，没有发现有价值的内容，因此我决定查看Calendar和Date的源代码. 在Calendar源代码中找到以下描述信息:

*示例: 考虑一个公历日历

由于9月31日将处于中间状态，因此该状态还会以秒或毫秒为单位吗？例如，业务代码在处理过程中获得的新Date（）的毫秒仅处于临界状态1000. 然后，在设置小时，分钟和秒之后，该毫秒将被四舍五入并变为00:00:00. 根据以下假设编写测试代码:

public static void main（String [] args）{

for（int i = 0; i

尝试{

现在的日期=新的Date（）;

日历cl = Calendar.getInstance（）;

cl.setTime（now）;

// cl.set（Calendar.MILLISECOND，1000）;

如果（cl.get（Calendar.MILLISECOND）

Thread.sleep（100）; //将时间关闭到超过900毫秒

继续;

}

System.out.print（cl.get（Calendar.MILLISECOND）+“ ::”）;

now = new Date（）;

System.out.print（now +“” + getEndTime（now，7）+“”）;

日期= lastMoment（现在）;

Thread.sleep（1）;

System.out.println（date）;

}捕获（InterruptedException e）{

e.printStackTrace（）;

}

}

}

尽管毫秒数接近999，但没有神奇的结果，这个结果也不例外. 数小时，数分钟和数秒没有临界状态，这类似于一天. 实际上，我认为之后是对的. 毕竟，小时，分钟和秒的上限是固定不变的. 只有一天的月份上限会不稳定，例如2月28日29日，3月31日等等.

调试三小步:

持续拒绝是成长的唯一途径. 如果您有一段时间没有任何想法，请充分饮食，然后第二天考虑一下（当然，前提是生产环境已解决了该问题）. 第二天是今天，我开始重新考虑此错误. 由于代码层和jdk层没有问题，因此它与或中间件有关吗？遵循这个想法来查看该实体类的字段类型以及表字段和ddl的绑定类型

@Temporal（TemporalType.TIMESTAMP）

私有日期endDate;

endDate`日期时间默认为空，

突然认为的日期时间可能会舍入毫秒，并且ddl中的默认日期时间为0，这意味着没有毫秒存储，因此出现了这种错误. 让我们讨论一下结果并创建一个测试表:

使用测试；

CREATE TABLE jamtest（

id INT（11）NOT NULL AUTO_INCREMENT，

date1 datetime NULL，

date2 datetime（2）NULLmysql 获取当前毫秒，

主键（id）

）引擎= INNODB默认字符

SET = utf8 COLLATE = utf8_general_ci;

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-284855-1.html