java集群优化——ORM框架查询优化原理

        众所周知,当下的流行的企业级架构中,ORM一直是最基础的部分,在架构设计的底层,对逻辑层提供面向对象的操作支持,而事实总是和我们预想的有所偏差,ORM在提供了较好的操作体验时,也流失了一部分原生SQL的灵活性与高效性,当然,这个问题不影响我们使用ORM框架,但是却阻碍了我们网站流量的提升,尤其是在企业级的多关系复杂查询方面,性能瓶颈是不得不提的部分!

        针对此问题,大多数的ORM框架提供一个折中的解决方案,就是在查询语句中,构造一个对象,可以是一个Entity,也可以是Map等,这样的方案,很大程度上解决了级联查询的问题,今天,我们一起来揭开这层面纱,看看这里的优化,是如何做到的!

现象:        

先看看我们的实验中用到的几个实体



大家可以看到中间的学生实体,和其他的实体关联太多,如果我们使用一般的查询语句会变得非常缓慢,我们测试在查询10条记录,不开启懒加载的前提下,10分钟这些数据都不能加载,大家看看日志文件,发的sql语句:

原因

查询语句:

From Student  where isDlete=0 

日志文件:


        这只是一小部分,我们做的统计是,发出了241条查询语句,这样的结果是客户不能容忍的,通过研究,我们发现直接发 from 虽然可以返回对象,但是严重拖慢查询效率,在from前加select语句,就会好很多,因为加上select后,就会组合成join语句,最后只发一天sql语句,对效率的提升是明显的!

总结:

        一个问题的解决方法,有时候会非常简单,而又对自己当初的设计懊悔不已,其实这都是一个过程,一个财富,我们遇到的每一个问题,都是为了让我们在以后的设计中有更好的想法,当然更重要的一点就是那别人撞的头破血流的经验作为自己的经验,提升自己的能力,这也是企业喜欢见到的!

转载于:https://my.oschina.net/u/3627638/blog/1489450

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值