应当怎样减少查询数据库减少了数据冗余的次数

来源：蜘蛛抓取(WebSpider) 时间：2017-05-07 20:30 标签： 数据库查询次数
在这种业务情况下，如何减少访问数据库的次数？对业务进行优化？
目前是订单分很多种类型的，不同类型的订单是不同的订单表。
然后在页面有个查询全部订单类型的业务。
现在做的是在后台用union并的一个查询结果，但是结果是sql查询的语句特别长。
或者我想分成多个sql去查询，然后在java中把结果集并起来，但是又没一个很好的方案，一方面一个业务访问了多次的数据库，而且还需要自定义排序。
不知道大家遇到这样的问题一般是怎么去解决的呢？
为什么不尝试做缓存呢？比如通过订单编号去做订单所有数据的json缓存放到一张表里面去。获取所有时直接读取这个缓存表就是
--- 共有 3 条评论 ---
: 戳到痛处了，更新其实很蛋疼的，我是把缓存的时间很短的，其实一个用户在短时间内不会频繁操纵订单的。这不是长久之计，所以在想办法改。
: 呃，我怎么觉得还是用MySql替代memcached在你这种环境下好用点呢，可以查询时分页。不过你这种应用也行，只是在逻辑上好像要复杂点，你是怎么实现缓存更新的呢？
其实是加了缓存的，用的是memcached。第一次查询会慢点，第二次就快很多了，因为订单查询是带分页的，所以key里面带上了分页的页码，又觉得有点浪费了。
方案一、楼上提到的缓存技术。
方案二、数据库的视图，或者存储过程解决，会让你的sql语句变的简洁。
方案三、加入一层nosql数据库做缓存，把经常并且复杂的表缓存到文档型nosql数据库，比如mongodb中，前台页面查询时无需sql，业务逻辑也变的简单起来。
--- 共有 2 条评论 ---
戳到痛处了，更新其实很蛋疼的，我是把缓存的时间很短的，其实一个用户在短时间内不会频繁操纵订单的。这不是长久之计，所以在想办法改。
好的，非常感谢。 的确，现阶段可能我先优化一下sql，如果效率不理想的话想办法用视图或者存储过程。 目前是因为对nosql没用过，项目进度赶的挺紧的，所以一下子上nosql的风险没把握，但是也是很好的思路，想办法在改善的阶段解决这个问题。
以前搞过，把必要的表里的必要数据检出，在java里搞，写点代码而已，当时是，4g内存，一千万左右选出五百多万，只能两三个人同时搞搞，很容易内存溢出。缓存第一慢的问题，有个笨办法，在服务启动时先搞一下，等用的时候，都是第二次以后了。视图其实不错的，把索引建好。
--- 共有 3 条评论 ---
是的，每个订单类型是不同的表，每个表的结构也是不一样的。
: 每种类型的订单是一个独立的表么？
(⊙v⊙)嗯。。放在java里面并一下是很方便的，但是不可避免的是，比如我有4个订单类型，一个是全部，一个是食品、家电、生活用品。
这样查询全部订单类型的时候，把其他3个类型的订单查询并起来，还是会有3次访问数据库的过程。
可以使用TCSQL,把所有的订单号和订单类型单独存储，方便查询
--- 共有 3 条评论 ---
: 其实是做了共同的属性存储的，但是每个订单类型有其他各个业务不同的属性，所以查询的时候还是去查各个订单表了。
: 你的订单应该有共同属性，把订单的共同属性单独存储，实际就是把查询条件的字段单独存储
嘿嘿，回头试一下，其实订单不知道啥时候用户去会查询，而且每个用户看到的还不一样。 可能是需要提前做一些预处理。
订单一经生成，还会有改动吗？我之前有遇到价格会改动，或者收货人会改动，或者备注什么的。
我用memcached做永远缓存，如果有改动某一个，就删除对应的order_key,然后生成一次到memcached。单个查的时候就飞速。
列表就用索引，把要查的条件做联合索引。然后再对应查order_key.一般列表不会超过100条吧。
不过我建议用sphinx做个全文索引，那就爽多了。（5亿条都不是事）
--- 共有 5 条评论 ---
: 内容其实现在不是很多，但是用户量一旦大的话，可能就比较多了。
: 嘿嘿，如果后期没变动的话，我尝试用存储过程吧，的确挺蛋疼的。
: mysql的text才64k,你里面有10个text?（bigtext就蛋碎）
: 太写就写存储过程。
这个还是会有改动的哦。 如果全部放到缓存里面的话的确也是一个不错的方案。但是每个用户看到的订单内容是不一样的，这样缓存大小就不是一个可控的， 可能现在可以，时间长的话可能就很大了。
联合索引的方法还没试试呢，现在我都是用union all的的方法去并结果集的，结果订单类型比较多的时候，sql代码也很长，不便于维护。
引用来自“梦想岛”的评论
订单一经生成，还会有改动吗？我之前有遇到价格会改动，或者收货人会改动，或者备注什么的。
我用memcached做永远缓存，如果有改动某一个，就删除对应的order_key,然后生成一次到memcached。单个查的时候就飞速。
列表就用索引，把要查的条件做联合索引。然后再对应查order_key.一般列表不会超过100条吧。
不过我建议用sphinx做个全文索引，那就爽多了。（5亿条都不是事）
我同意楼主的做法，sphinx还是很好用的，我们以前用nosql,后台都改成sphinx了。nosql也是有瓶颈的
还是从业务上减少查询数据量吧；比如多加几个标签：今日订单、昨日订单、本周订单、本月订单、上月订单，这样对用户更易使用，对数据库压力也减小不少
--- 共有 2 条评论 ---
如果查询项都在一张表中，那么可以先查询减小数据集，然后再做数据关联查询
是哒，目前是分订单类型查询的。 但是订单是由 基础订单+业务订单 两张表的数据关联起来查询到的。2010年 总版技术专家分年内排行榜第一2009年 总版技术专家分年内排行榜第一
2011年 总版技术专家分年内排行榜第二
本帖子已过去太久远了，不再提供回复功能。

我要回帖

更多关于 数据库查询次数 的文章

 

随机推荐