戳实现两个时间戳相减获取时间间隔的MySQL方法mysql中两个时间

哎，就是那个，MySQL里算时间戳差儿，咋算来着...
就说2 02 2 年吧，某个城市，比如北京，搞个事儿，需要算两个时间戳。

一种方法是TIMESTAMPDIFF()，这玩意儿挺好使。

就比如，你有两个时间戳，一个'2 02 2 -01 -01 08 :00:00'，一个'2 02 2 -01 -01 09 :3 0:00'。

你用TIMESTAMPDIFF(SECOND, '2 02 2 -01 -01 08 :00:00', '2 02 2 -01 -01 09 :3 0:00')；
那结果就是啥？就是9 00秒，对吧。

你要是算小时，TIMESTAMPDIFF(HOUR, '2 02 2 -01 -01 08 :00:00', '2 02 2 -01 -01 09 :3 0:00')；
结果就是1 小时。

你看，这个函数挺好，直接给你秒、分、时、天、周、月、年，挑着用。

再一个方法，就是UNIX_TIMESTAMP()。

这玩意儿把日期时间转成秒数，就是从1 9 7 0年开始算的秒数。

你用UNIX_TIMESTAMP('2 02 2 -01 -01 08 :00:00')，得到一个数。

再用UNIX_TIMESTAMP('2 02 2 -01 -01 09 :3 0:00')，得到另一个数。

然后你用后一个数减前一个数，比如，9 00秒。

你要是想看小时，就9 00 / 3 6 00，得1 小时。

我当时也懵，咋回事儿，后来才反应过来，这俩方法其实差不多。

就是TIMESTAMPDIFF直接给你算好了，省事儿。

UNIX_TIMESTAMP得自己减自己，再换算，稍微麻烦点。

可能我偏激，觉得TIMESTAMPDIFF更好用。

反正，这两种方法，你看着用，咋方便咋来。

就这事儿。

MySQL Connect/J 8.0时区陷阱

MySQLConnect/J8 .0时区陷阱直接加参数或改数据库配置。

加Asia/Shanghai或GMT%2 B8 到连接参数。

改MySQL time_zone为+8 :00。

升级后新数据要手动修时间。

Boot1 .5 用系统时区，Boot2 .0用数据库时区。

确保读写时区一致，避免偏差。

你自己掂量。

MySQL 5.7中如何高效筛选相邻数据时间差值超过5分钟的数据？

嘿，兄弟，最近在搞数据库这事儿啊？我以前也踩过不少坑，今天就来聊聊这个筛选相邻记录时间差值的问题。

记得那会儿，我在一个项目里，得在MySQL5 .7 里筛选出相邻记录时间差超过5 分钟的数据。
那时候，5 .7 还不支持窗口函数，所以得另想办法。
我试了三种方案，各有各的坑。

先说方案一吧，就是利用变量计算时间差。
这个方法适用于那种不能修改表结构，又得快速实现的情况。
原理就是用一个用户变量@tmp来存储上一条记录的时间，然后计算当前记录和上一条的时间差。
记得当时我初始化变量@tmp为一个极早的时间，就是为了避免首条记录被误判。
然后，在子查询里按时间排序，确保时间顺序正确。
最后，在外层查询里筛选diff大于3 00的记录。
这个方法的好处是不需要修改表结构，逻辑也比较简单。
不过，缺点是变量操作在复杂查询中可能不稳定，大数据量时性能会稍微有点降。

然后是方案二，这个方法得先修改表结构，添加个自增主键。
原理是通过自增主键id关联相邻记录，直接计算时间差。
当时我写了个JOIN操作，关联相邻记录，然后筛选时间差大于3 00的记录。
这个方法效率最高，JOIN操作优化得也不错。
不过，缺点是得修改表结构，可能影响到现有的业务。

最后是方案三，这个方法就是用用户变量模拟行号，但我不推荐用这个。
原理是通过变量生成行号，模拟窗口函数的功能。
这个方法性能差，维护成本高，大数据量时性能会显著下降。

当时我优先选择了方案二，因为项目里可以修改表结构，追求的是最高效率。
如果实在不能修改表结构，就选方案一。
方案三就当个备选，但一般不推荐用。

注意事项嘛，得确保数据按time_column排序，变量初始化要正确，执行前备份表以防意外，还有为time_column添加索引，这样可以提升筛选当天数据的速度。

这事儿，兄弟，你遇到过没？或者你有更好的方法？咱们聊聊呗。