Mysql 探讨一个日期对比不经意写的坑
问题原因:mysql 在处理数据总经常会用到日期对比,在日期对比中,使用了不正确日期,或者方式,可能导致我们处理数据产生异常,但是也没报错
先来看一个sql:
select UNIX_TIMESTAMP('2023-04-20') > UNIX_TIMESTAMP('2023-04-31'),UNIX_TIMESTAMP('2023-04-31'),UNIX_TIMESTAMP('2023-04-20')
正常理解: 2023-04-20
> 2023-04-31
这个应该是正常操作 结果在字符串对比中 是 false
但是在 mysql 计算中这个由于是日期类型结果是true
实际的原因是我们不小心写了 4-31 在日历中是小月,没有31号,所以mysql 在转换中成了空,出现不符合预期的结果
另外一个就是我们有时候会做一些统计 存储的格式可能是字符串
如果 月份 存储成 2023-9
不带前置0的月份
如果对比
select '2023-9' > '2023-10'
如果我们在使用字符串填充月份或者周添加了前置0
所以我们在存储日期类型为字符串的时候,一定要确保带上前置0 ,字符串对比是按照字符对比的,这是在排查问题发现的一个小逻辑
本作品采用《CC 协议》,转载必须注明作者和本文链接
看了一下,应该跟mysql没关系,主要是平时代码不规范导致的,建议加强代码规范,真的能少走很多弯路
这不就是字符串对比吗
建议不要在mysql做时间的转化,而是通过代码转换成所需要的格式直接在SQL语句里使用。
比较习惯存储时间戳,直接数字进行比较大小不是更好吗?数据量小还好,如果查出的数据量很大,UNIX_TIMESTAMP 每次都要计算,感觉挺要命的