Chinaunix

标题: 【讨论中】遇到个大数据表的问题 1个月的数据在2G左右 [打印本页]

作者: badeager 时间: 2012-09-15 17:51
标题: 【讨论中】遇到个大数据表的问题 1个月的数据在2G左右
本帖最后由 cenalulu 于 2012-09-17 09:20 编辑

创建了一个表，字段有20多个，数据一个月表大小2G-4G，
数据记录在8000万左右，
结果造成了查询一个数据记录需要20多秒，
搜索采用了多步查询，
  select  a from  testtable group by a
  select b from testtable where a='??' group by b
  ....
  基本数据是这样子的，

  针对这样的表，有什么优化的方法？

作者: fengshijie 时间: 2012-09-16 20:04
遇到同样的问题，我的数据比你的还大。。。不晓得mysql是不是可以承受得住

作者: chinafenghao 时间: 2012-09-17 10:26
本帖最后由 chinafenghao 于 2012-09-17 10:27 编辑

回复 1# badeager

楼主的硬件估计不太给力了，所以要想方法来处理了。
看你的sql，主要是where a group by b。
可以考虑一下几种方案。
1、使用分区表，以a为键来分区，这样每次group by就在一个分区里。
2、group by最好能够limit一下。
3、group by b的目的我不太清楚，如果你是为了取数量，你可以做一个临时表，不用实时跑。
4、硬件方面，这种group by肯定会用到临时表。所以可以监控硬件，group的时候哪方面的硬件资源不足，可以适当增加一些。
5、可以考虑将日志转出到infobright引擎做查询，效率会高非常多

作者: cenalulu 时间: 2012-09-17 10:28
单从语句来看，最直接的是加 (a,b)的联合索引。
这两个语句如果有这个联合索引，在8000w的数据量下应该是不成问题的。

后期的优化可以参考楼上的意见，分区，历史数据清理，转入数据仓库处理等

作者: kerlion 时间: 2012-09-18 10:06
提示: 作者被禁止或删除内容自动屏蔽

作者: badeager 时间: 2012-09-18 10:24
现在因为是数据库比较老， MYSQL5.1以下，导致了没有办法使用分区，不过后期决定解决。
还想问一个问题，分区可以做多层次的子分区吗？

可能分表也是个不错的选择

作者: shang2010 时间: 2012-09-18 15:18
本帖最后由 shang2010 于 2012-09-18 15:20 编辑

@chinafenghao 1、使用分区表，以a为键来分区，这样每次group by就在一个分区里。

从理论上讲，应该以b为分区键的说才为合理，，这样多个分区可以并行计算。。。

不太懂mysql，，请拍砖

作者: shang2010 时间: 2012-09-18 15:21
@fengshijie

业务优化最先。。

作者: chinafenghao 时间: 2012-09-19 12:33
@shang2010 where a = '' group by b.
如果按b来分区的话，where a的时候对磁盘的IO还是很比较大。读不存在并发问题，主要是IO问题。

我是这么理解的，

作者: chinafenghao 时间: 2012-09-19 12:34
@cenalulu
嗯，如果没有where b这种和直接group by b。联合索引肯定比单独做两个索引好。

作者: chinafenghao 时间: 2012-09-19 12:35
其实看楼主的描述，这个应该是他的一个测试，不是业务环境。应该最大的问题是硬件。

作者: shang2010 时间: 2012-09-19 12:48

chinafenghao 发表于 2012-09-19 12:35
其实看楼主的描述，这个应该是他的一个测试，不是业务环境。应该最大的问题是硬件。

对，跑这么大的业务舍不得花钱是心病{:3_188:}

作者: rucypli 时间: 2012-09-19 13:15
select a from testtable group by a
这种在八千万的表上能快才怪建议把结果集记录在小表上没十分钟执行一次把执行结果覆盖

作者: badeager 时间: 2012-09-22 21:03
呵呵，现在只是测试，不过，以后会是业务的，机器不是问题，但是性能肯定是个问题，所以决定最后肯定需要分表，可能会涉及到分区。
这样应该可以解决这个问题。

作者: zhangshengdong 时间: 2012-09-24 10:18
具体思路：

(1)先通过索引优化。

(2)如果不成功，可以，分区，清除历史数据，或者把表直接拆分出来。单独做OLAP。

作者: action08 时间: 2012-09-28 17:32

zhangshengdong 发表于 2012-09-24 10:18
具体思路：

(1)先通过索引优化。

OLAP是什么哦?好用不？

作者: badeager 时间: 2012-10-04 10:58
后来发现，硬件问题固然是一个点，但是硬件绝对没有办法完全解决这个问题。
现在采用了分表的方式，很好的解决了两个多月，近三个月的数据查询。
但是下一步还是需要分区，　以保证每个区的数据大小需要维持在这个状态即可。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)