项目场景:
这次在开发中碰到了一个不大不小的问题,需求要求根据查询出的两个字段进行排序,字段1(带有日期的字符串)根据日期进行降序排序,字段2(带有序号的字符串)根据序号进行升序排序,所以我可以将两个字段中的日期或序号提取出来,进行排序。
例:字段1 :2020年03月 提取出 202003
2021年度/2021年 提取出 202112 (表示2021年的第12月)
2021年第2季度 提取出 202106 (表示2021年的第6月)
字段2:附件1 提取出 1 / 附件2 提取出 2
就这样我将查询出的两个字段通过sql处理,提取出其中的数值作为两个新的字段,然后进行降序和升序。
问题描述:
然而在这里就遇到问题了,刚开始在本地自测的时候排序正常,也是按照 202101 202009 201903 201806 等等这些数值进行正常降序排序,但是到测试环境就发现问题了,测试环境有一些数据处理之后是 202212 ,结果排序结果变成了 202101 202009 201903 201806 202212 这样的了,明显 202212 数据位置本来应该是要排在前面的,但是现在确是在最后面了,说明排序出问题了。
原因分析:
首先开始检查代码,看看会不会是因为代码在逻辑层面对排序数据进行了影响,但其实并没有;
然后突然想到了处理过的字段虽然提取的数值是数字,但其实本质上处理后的数据类型是字符串类型的形式,虽然字符串形式的数值会一位一位进行一样比对,但是因为字符的排序顺序会根据编码类型的不同,排序顺序也可能会不一样,那就更不用说和数字一样按12345...的顺序排序了,所以就需要把处理过后提取出的数值,转换成数字类型的数据后,再进行排序
解决方案:
将 字符串类型的数字 转换成 数字类型,可以用MySQL的内置函数进行转换,但是我选择用更简单的方式进行处理:字段+0或*1,这样就将类型转换成为数值类型,果然自测的时候也根据测试环境相同的数据进行了测试,结果排序正常了,问题解决。
(っ °Д °;)っ(当然有时候知道解决方法了也还是可能会出错,有可能将解决方案用错地方了🤣
我将 字段+0 加在了 group by 字段1+0 desc, 字段2+0 asc ; 显然这样是并没有效果的,排序仍然出错,在这里我就有点怀疑自己的猜想了,直接百度大法,但是很多文章都是说MySQL排序语法的,后面经过一番思路复盘豁然开朗,我要在select 字段1+0, 字段2+0 才是真正将数据转换成功了,还好有惊无险的解决了😎)