最近的一些bug,今晚是线上发布产生的bug

难受啊,这个点守着发布,发布完还发现了bug,还在统一处理发版中,估计还要等段时间

其实都是细节,不够认真,或者可以说经验太少,没踩过坑,都是mybatis  sql语句失误

1.今晚的

起因:一条sql语句执行时间过长,查询原因是left join一张表时间耗费了一半多时间,于是我打算分成两个sql语句查询,

left join单独拎出来,这样执行主查询就快很多,在分页查询count的时候就节省了很多时间,分页好了,我们将查询到

的关联id放入list里,再执行left join里的语句,简单方便的实现了优化效果

结果:得到了关联id的list,我为了避免for多次连接数据库,所以用in一次查询出来,关键来了,id的list为null,整条sql

崩溃。想的不够严谨。

2.前几天的

Store store = storeMapper.findOneById(id);

if(store.getType == StoreType.IN){

       return 1;

}else{

    return 2;

}

理想是返回1的,因为数据库就是IN,但奇怪的现象发生了,为什么是2呢?

一串类似这么简单的代码,会有什么影响到了呢?看下前后逻辑代码,没有问题啊。看难道if else都会有问题?

去测试环境看看日志,进入的确实是2里面的代码,难道有人覆盖了我的代码?

去部署测试的分支看看,代码和我的一样啊。

这么简单的逻辑,这么简单的代码, 不报错,感觉自闭了啊。

结果:濒临之际,灵光一闪,会不会type这个值没返回啊,毕竟这是mybaties自定义sql,果然。。。。。。。。耗了我半小时

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

3wtczs93点抗母

钱癌晚期

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值