Mysql 探讨一个日期对比不经意写的坑

问题原因:mysql 在处理数据总经常会用到日期对比,在日期对比中,使用了不正确日期,或者方式,可能导致我们处理数据产生异常,但是也没报错

先来看一个sql:

select UNIX_TIMESTAMP('2023-04-20') > UNIX_TIMESTAMP('2023-04-31'),UNIX_TIMESTAMP('2023-04-31'),UNIX_TIMESTAMP('2023-04-20')

Mysql 探讨一个日期对比不经意写的坑

正常理解: 2023-04-20 > 2023-04-31 这个应该是正常操作 结果在字符串对比中 是 false 但是在 mysql 计算中这个由于是日期类型结果是true 实际的原因是我们不小心写了 4-31 在日历中是小月,没有31号,所以mysql 在转换中成了空,出现不符合预期的结果

另外一个就是我们有时候会做一些统计 存储的格式可能是字符串

如果 月份 存储成 2023-9 不带前置0的月份
如果对比

select '2023-9' > '2023-10' 

Mysql 探讨一个日期对比不经意写的坑

如果我们在使用字符串填充月份或者周添加了前置0

Mysql 探讨一个日期对比不经意写的坑

所以我们在存储日期类型为字符串的时候,一定要确保带上前置0 ,字符串对比是按照字符对比的,这是在排查问题发现的一个小逻辑

本作品采用《CC 协议》,转载必须注明作者和本文链接
每天一点小知识,到那都是大佬,哈哈
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 7

看了一下,应该跟mysql没关系,主要是平时代码不规范导致的,建议加强代码规范,真的能少走很多弯路

1年前 评论
raybon (楼主) 1年前

这不就是字符串对比吗

1年前 评论
raybon (楼主) 1年前

建议不要在mysql做时间的转化,而是通过代码转换成所需要的格式直接在SQL语句里使用。

1年前 评论

比较习惯存储时间戳,直接数字进行比较大小不是更好吗?数据量小还好,如果查出的数据量很大,UNIX_TIMESTAMP 每次都要计算,感觉挺要命的

1年前 评论
raybon (楼主) 1年前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!