mysql的一个日常用法的BUG

一直以来,使用mysql,在统计时间差时,都是使用TIME_TO_SEC(timediff(d2,d1))的方式来处理。

今天偶然发现,该用法,存在BUG,例如:

select 
TIME_TO_SEC(timediff('2014-02-28 10:13:35', '2013-12-28 14:03:37')) as times0, 
timestampdiff(second, '2014-02-08 14:03:37', '2014-02-28 10:13:35') as times1,
TIME_TO_SEC(timediff('2014-02-28 10:13:35', '2014-02-08 14:03:37')) as times2, 
timestampdiff(second, '2013-12-28 14:03:37', '2014-02-28 10:13:35') as times3

执行结果:


很明显,times0应该等于times3,times1应该等于times2,但是,实际上,times0不等于times3。


进行更多实验,你会发现,TIME_TO_SEC(timediff(d2,d1))的用法,在时间跨度达到一定的情况下,其结果都是3020399。

具体这个跨度最大值是多少,以及为什么会出现这样的结果,有待去考究,暂记备忘。


最后建议大家使用timestampdiff来进行时间差的计算。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
关于 Java 线程池导致 MySQLBug,可能是由于线程池中的线程数量过多,导致 MySQL 连接池被耗尽,从而出现连接超时或者连接泄露的情况。这种情况下,可以通过优化线程池的配置,增加 MySQL 连接池的大小,或者使用连接池管理工具进行监控和管理,来避免这种情况的发生。 至于关于线程池的问题,可以具体分为以下几个方面: 1. 线程池的大小:线程池的大小需要根据实际的业务场景来进行设置,如果线程池的大小过小,可能会导致任务无法及时处理,而过大则会占用过多的系统资源,影响系统的性能表现。 2. 线程池的类型:线程池的类型包括 FixedThreadPool、CachedThreadPool、ScheduledThreadPool 等,不同类型的线程池适用于不同的场景,需要根据实际的业务需求进行选择。 3. 线程池的拒绝策略:当线程池中的任务数量超过线程池的最大容量时,需要采取一定的拒绝策略,如 AbortPolicy、CallerRunsPolicy、DiscardOldestPolicy 等,需要根据业务场景和系统性能要求进行选择。 4. 线程池的生命周期管理:线程池的生命周期包括创建、启动、运行、停止等多个阶段,在使用线程池时需要对其进行合理的生命周期管理,以确保线程池的稳定运行和性能表现。 总之,线程池是一个非常重要的并发编程工具,需要在实践中不断学习和积累经验,以提高系统的性能和稳定性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值