今天写出一个十分弱智的bug!

来源:www.cnblogs.com/supercj/p/10333918.html

今天写出一个十分弱智的bug,记录一下,提醒自己以后别这种犯错,不怕丢人哈~

在写一个分页查询记录的sql时,要根据添加的时间逆序分页输出,之前的写法是酱紫:

select
    record.a,
    y.c
from
    (
        select
            a,b
        from
            x
        order by timestamp desc
        limit 0,10
    ) record
left join y
on record.b = y.d;

因为一些新的需求,要在后面加一些where条件,limit操作不能在嵌套查询里面加了,于是乎把limit 0,10提出来放到最外面,结果order by还留在里面。

我当时想嵌套查询出来的record表已经按timestamp字段逆序排列了,再left另一张表,最终再limit出来的结果应该也是逆序的,但结果却很打脸,是正序的。

首先控制变量,代码回滚到之前,把后来加的各种逻辑都去掉,还原到上述sql,只把limit 0,10移到最后,发现timestamp是正序的,那么问题应该就出在这里了,与后来加的其他逻辑没有关系。

那么再试一下删掉limit操作,结果timestamp是无序的!

这不可能啊,于是认真看了下数据,发现一些规律,可能是按y表的自增id或created_at时间字段排序的(因为这两个字段是索引字段),那么到这里,我们至少可以得到一个简单的结论,就是联表查询结果,不是按照嵌套查询中的order by排序的,现在正向一看,确实不可能按这个排序,因为括号里面的逻辑对括号外是不可见的。

还有个问题,上述去掉limit后,最终不是按left join主表的顺序输出,按照我们常理想象,mysql是循环主表的记录去关联另一张表,那么输出的顺序应该还是主表的顺序啊,但结果却是按另一张表的字段排序的,这又是为什么呢?


去官方手册中找找线索,发现order by模块中有这么一句话。

再去limit模块中看一下

从以上两个截图中,我们可以发现一些端倪,limit操作会对查询有一些优化,查询到指定条数的数据,就可以提前结束了,比如我们本文中的left操作,拿到10条结果就结束查询线程,返回客户端。

我猜测,如果没有limit操作,反正全部都要join,可能mysql会对循环逻辑做一些优化,不一定要按主表来循环,思想类似于java编译中的重排序,也对应了上面截图中的那句话。

采用最简单、最粗暴的方式,直接把order by 和 limit操作放到最外面就ok啦,其实效率上并没有什么降低,只要索引建的合理即可。

最近热文阅读:

1、Redis10亿数据量只需要100MB内存,为什么这么牛?

2、为什么用了索引,查询还是慢?

3、Spring 为啥默认把bean设计成单例的?这篇讲的明明白白的

4、java中double类型精度丢失问题及解决方法

5、14 款牛逼的 IDEA 插件,让你开发速度飞起来!

6、JVM 发生 OOM 的 8 种原因、及解决办法

7、我把SpringBoot项目从18.18M瘦身到0.18M,部署起来真省事!

8、面试必问的一致性Hash在负载均衡中的应用

9、Java开发必须掌握的 20+ 种 Spring 常用注解

10、来了来了!Chrome 高级玩法,秒变摸鱼神器(提前尝鲜还未发布的功能)

关注公众号,你想要的Java都在这里

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值