新手问题 数据库数据太多,多表检索非常缓慢,有什么好的解决办法么?

jerrym · 2015年09月17日 · 最后由 dy1901 回复于 2015年09月22日 · 7719 次阅读

数据库数据太多,多表检索非常缓慢,有什么好的解决办法么?

用了 view,没有什么改善,哪位有好的办法,谢谢了。

笼统回答: 用 explain

偷懒:使用缓存,定期更新

具体:要知道几张表,有没有索引,数据量大小等等

反模式,冗余,建缓存表,对那种读占多数的情况很适用。

比如一个 post 有用户 id,如果要找出用户名,要联查用户表,这时候建立一个用户名字段,在早期生成 post 的时候就写进去,这样显示 post 就不用联查 用户表了。

数据一致性通过程序保证,比如改用户名,那就要在其它有用户名字段的地方也要相应修改。

1、在设计之初,考虑数据增长趋势,建立合适的索引。 2、表关联的外键建立索引。 3、建立一些冗余数据,来避免 join 查询

@peter 所说的一样

比如两个表 deals(tb_shop_id) 和 tb_shops(wangwang, name.....) 。经常有这种需求,根据 wangwang 去查询deals 数据 一般写法

SELECT deals.*
FROM deals INNER JOIN tb_shops ON deals.tb_shop_id = tb_shops.id
WHERE tb_shops.wangwang='xxxxxx'

但是,如果在设计之初,考虑到这种需求,那么在表 deals上记录 tb_shop_id 和 wangwang,那么就不需要 join 表查询了。 只有在 tb_shops.wangwang 修改的时候同步 deals 表 如下:

SELECT deals.*
FROM deals 
WHERE deals.wangwang = 'xxxxxx'

4、数据库良好的设计,一定要,所见及所得,避免复杂的查询。 比如日志表,xxxx_logs 可能会有百万或千万的数据。那么避免对这个表做任何查询。可以根据需求建立几个小的统计表。 比如,商家每天的消费情况,商家的总消费情况,所有的数据在存入 xxxx_logs 的时候,对应把数据同步到这几个小表中。

商家每日消费情况表tb_shop_day_details,商家总消费情况tb_shops_total_details

比如查看所有商家的总消费情况,只需要查询 tb_shops_total_details 不再需要从 xxxx_logs 临时计算数据,返回。 比如,要查看商家2014-11-11那一天消费的情况,那么也只需要

SELECT *
FROM tb_shop_day_details
WHERE st_date = '2014-11-11'

所有数据所见及所得,那么这种情况就不需要 JOIN 表操作。

5、将多表的数据查询,提前汇总到一个表。在真正需要查询的时候,从该汇总表中查询。

6、读写分离。在主库写,从库读。

7、将多表 join 查询,改成几条简单的 SQL 查询,最后在组合数据。

8、如果觉得上述的太麻烦,使用 solr 吧,但是原理是一样的,将预计要查询的汇总在一个表。

其实多表查询慢,第一、没有建立合适的索引,第二,存在不良的表结构设计。 在系统初期,没有做好设计。导致数据增长不可控,不良的表结构设计,肯定会导致多表查询慢。 要解决多表查询缓慢的问题,从修改表结构开始,一步一步优化,肯定能达到预期的效果。

a million dollar question.

#3 楼 @ibugs 需求天天在换, 昨天的 1 对多明天就是多对多, 过几天回来又变成 1 对 1. 在系统初期做好设计,这种说法有点不切实际.

现在主要的问题是数据库中的数据太多,主表里就有60多万条数据,加了index,做了view还是非常的慢。 我已经想不到别的办法了。

#6 楼 @jerrym 楼主,60 万数据一点都不多啊,不涉及机密的情况下,能具体说一下吗?

@MrPasserby 产品是开发的死对头。一般遇到这种问题,都会详细的了解需求,确定是否要该表结构。 一般遇到这种频繁修改表结构的需求,至少都会在我这边自动屏蔽。

SO,一个好的产品,很关键。

@jerrym 60W 的数据一点都不多,我们的表经常是上百万,千万的,合适的表结构,恰当的索引,都会大大减少查询的时间。

#6 楼 @jerrym 应该是索引没用好

#6 楼 @jerrym 业务复杂了以后加索引可以根据慢查询记录来做,有针对的来加索引。一般来说正常配置的机器上面,mysql 数据量在千万以下的级别,不会有性能问题,60w 的库完全算不上大,觉得访问慢那基本是在扫表~

建议楼主详细看看关于 mysql 索引的资料,优化的时候多用用 explain,看看查询到底有没有命中索引。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册