投机取巧的查询优化

文章讲述了作者在处理涉及多个大表的关联查询时,尝试在内存中进行数据预处理以提高性能,但随着数据量的增长导致内存溢出,功能失效。作者借此反思,业余解决方案不适合处理大规模数据问题。

当一个功能涉及到很多个表的时候,尤其是其中存在>=1个大表时,关联查询起来就很头疼(啊!好慢啊查询的),这可怎么办呀~

虽然关联查询很慢,但是每个表单独查询快啊,于是我萌生出一个想法,数据全查出来,在内存里关联,lambda表达式-> group by  sum  count  等功能全部发挥出来,最终速度简直了,质的飞跃, 这就叫用空间换时间吧~~

可是好景不长,我们 的数据疯狂 成长,这种查询也逐渐慢了起来.直到有一天,内存溢出了~ 完了,小弟把项目干崩溃了,糟糕糟糕,无奈暂时关闭功能。

通过这次教训,我还是深刻意识到了自己的错误,在什么地方就干什么事,业余的功能,不能拿来专用!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值