在这种业务情况下,如何减少访问数据库的次数?对业务进行优化?

在这种业务情况下,如何减少访问数据库的次数?对业务进行优化?

自此以后,行同陌路 发布于 2021-11-26 字数 400 浏览 921 回复 25

目前是订单分很多种类型的,不同类型的订单是不同的订单表。

然后在页面有个查询全部订单类型的业务。

现在做的是在后台用union并的一个查询结果,但是结果是sql查询的语句特别长。

或者我想分成多个sql去查询,然后在java中把结果集并起来,但是又没一个很好的方案,一方面一个业务访问了多次的数据库,而且还需要自定义排序。

不知道大家遇到这样的问题一般是怎么去解决的呢?

如果你对这篇文章有疑问,欢迎到本站 社区 发帖提问或使用手Q扫描下方二维码加群参与讨论,获取更多帮助。

扫码加入群聊

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(25

一个人的旅程 2021-12-01 25 楼

是哒,目前是分订单类型查询的。 但是订单是由 基础订单+业务订单 两张表的数据关联起来查询到的。

坐在坟头思考人生 2021-12-01 24 楼

如果查询项都在一张表中,那么可以先查询减小数据集,然后再做数据关联查询

猫九 2021-12-01 23 楼

还是从业务上减少查询数据量吧;比如多加几个标签:今日订单、昨日订单、本周订单、本月订单、上月订单,这样对用户更易使用,对数据库压力也减小不少

旧伤慢歌 2021-12-01 22 楼

引用来自“梦想岛”的评论

订单一经生成,还会有改动吗?我之前有遇到价格会改动,或者收货人会改动,或者备注什么的。

我用memcached做永远缓存,如果有改动某一个,就删除对应的order_key,然后生成一次到memcached。单个查的时候就飞速。

列表就用索引,把要查的条件做联合索引。然后再对应查order_key.一般列表不会超过100条吧。

不过我建议用sphinx做个全文索引,那就爽多了。(5亿条都不是事)

墨洒年华 2021-12-01 21 楼

这个还是会有改动的哦。 如果全部放到缓存里面的话的确也是一个不错的方案。但是每个用户看到的订单内容是不一样的,这样缓存大小就不是一个可控的, 可能现在可以,时间长的话可能就很大了。 联合索引的方法还没试试呢,现在我都是用union all的的方法去并结果集的,结果订单类型比较多的时候,sql代码也很长,不便于维护。

緦唸λ蓇 2021-12-01 20 楼

回复
太写就写存储过程。

千笙结 2021-12-01 19 楼

回复
mysql的text才64k,你里面有10个text?(bigtext就蛋碎)

小瓶盖 2021-12-01 18 楼

回复
嘿嘿,如果后期没变动的话,我尝试用存储过程吧,的确挺蛋疼的。

浮生未歇 2021-12-01 17 楼

回复
内容其实现在不是很多,但是用户量一旦大的话,可能就比较多了。

甜扑 2021-12-01 16 楼

订单一经生成,还会有改动吗?我之前有遇到价格会改动,或者收货人会改动,或者备注什么的。

我用memcached做永远缓存,如果有改动某一个,就删除对应的order_key,然后生成一次到memcached。单个查的时候就飞速。

列表就用索引,把要查的条件做联合索引。然后再对应查order_key.一般列表不会超过100条吧。

不过我建议用sphinx做个全文索引,那就爽多了。(5亿条都不是事)

高跟鞋的旋律 2021-12-01 15 楼

嘿嘿,回头试一下,其实订单不知道啥时候用户去会查询,而且每个用户看到的还不一样。 可能是需要提前做一些预处理。

终止放荡 2021-12-01 14 楼

回复
你的订单应该有共同属性,把订单的共同属性单独存储,实际就是把查询条件的字段单独存储

画骨成沙 2021-12-01 13 楼

回复
其实是做了共同的属性存储的,但是每个订单类型有其他各个业务不同的属性,所以查询的时候还是去查各个订单表了。

爱你是孤单的心事 2021-12-01 12 楼

可以使用TCSQL,把所有的订单号和订单类型单独存储,方便查询

输什么也不输骨气 2021-12-01 11 楼

(⊙v⊙)嗯。。放在java里面并一下是很方便的,但是不可避免的是,比如我有4个订单类型,一个是全部,一个是食品、家电、生活用品。 这样查询全部订单类型的时候,把其他3个类型的订单查询并起来,还是会有3次访问数据库的过程。

离去的眼神 2021-12-01 10 楼

回复
每种类型的订单是一个独立的表么?

成熟的代价 2021-12-01 9 楼

是的,每个订单类型是不同的表,每个表的结构也是不一样的。

少女净妖师 2021-12-01 8 楼

以前搞过,把必要的表里的必要数据检出,在java里搞,写点代码而已,当时是,4g内存,一千万左右选出五百多万,只能两三个人同时搞搞,很容易内存溢出。缓存第一慢的问题,有个笨办法,在服务启动时先搞一下,等用的时候,都是第二次以后了。视图其实不错的,把索引建好。

别再吹冷风 2021-12-01 7 楼

好的,非常感谢。 的确,现阶段可能我先优化一下sql,如果效率不理想的话想办法用视图或者存储过程。 目前是因为对nosql没用过,项目进度赶的挺紧的,所以一下子上nosql的风险没把握,但是也是很好的思路,想办法在改善的阶段解决这个问题。

永不分离 2021-12-01 6 楼

戳到痛处了,更新其实很蛋疼的,我是把缓存的时间很短的,其实一个用户在短时间内不会频繁操纵订单的。这不是长久之计,所以在想办法改。

怎言笑 2021-12-01 5 楼

方案一、楼上提到的缓存技术。

方案二、数据库的视图,或者存储过程解决,会让你的sql语句变的简洁。

方案三、加入一层nosql数据库做缓存,把经常并且复杂的表缓存到文档型nosql数据库,比如mongodb中,前台页面查询时无需sql,业务逻辑也变的简单起来。

复古式 2021-12-01 4 楼

其实是加了缓存的,用的是memcached。第一次查询会慢点,第二次就快很多了,因为订单查询是带分页的,所以key里面带上了分页的页码,又觉得有点浪费了。

看透却不说透 2021-12-01 3 楼

回复
呃,我怎么觉得还是用MySql替代memcached在你这种环境下好用点呢,可以查询时分页。不过你这种应用也行,只是在逻辑上好像要复杂点,你是怎么实现缓存更新的呢?

葬花如无物 2021-12-01 2 楼

回复
戳到痛处了,更新其实很蛋疼的,我是把缓存的时间很短的,其实一个用户在短时间内不会频繁操纵订单的。这不是长久之计,所以在想办法改。

夜司空 2021-11-28 1 楼

为什么不尝试做缓存呢?比如通过订单编号去做订单所有数据的json缓存放到一张表里面去。获取所有时直接读取这个缓存表就是