用的是mysql数据库,有个表每天都会新增100--200万条数据
曾经考虑从业务上减小该表数据量,但是不符合需求。
现状就是每天都有起码100万条数据进入这个表, 但每个月该表都会自动清零,也就是说这个表的数据最多3000万--6000万条前台对这个表会做类似下面的Sql操作!
select 
    filed1, 
    sum(filed2+filed3) as sumFiled 
from 
    tabA 
where 
    filed4>? and 
    filed5=? and
    filed6=? and
    stime<=? and 
    stime>=? 
group by 1 
order by 2 
limit ? 
但由于数据量太大,响应的太慢了。不知道有没有什么办法啊。 也不奢望能有什么办法可以效率特别高,只是希望大家能提点优化的意见,哪怕提高一点也好啊。
麻烦大家了啊!
这个表现在的现状:1、表的字段不多,大概10个。 
2、现在就只做了pk的index,其他都没有做啊。 
3、表是innodb类型啊
4、暂时不能考虑集群。
5、Mysql也是默认安装的,没有修改任何的参数。
以前也听人说、什么垂直分割水平分割,什么用Insert的单独做,然后启动多个Mysql做集群,专门做查询用,什么的,但也不知道具体怎么做。
 现在思路就是,想从Mysql配置文件什么的做点优化, 然后从表这块做点优化。 
不知道有人能提供点优化办法吗?也不奢望能有什么办法可以有质的飞跃啊,只是希望大家能提点优化的意见,哪怕提高一点也好啊。5555
解决了放500分啊。感谢大家了很头疼555

解决方案 »

  1.   

    先创建分别基于
    filed4
    filed5
    filed6
    stime
    的索引,然后贴出你的 show index from tabA ;或者你能直接说明一下这些字段的中预计数据分布.
      

  2.   

    以前也听人说、什么垂直分割水平分割,什么用Insert的单独做,然后启动多个Mysql做集群,专门做查询用,什么的,但也不知道具体怎么做。 可能是这个意思。
    一台服务器(实时数据库服务器)专门insert;另外一台备份数据库服务器专门select,根据查询条件建索引。10分钟左右备份一次(根据实际情况定)
      

  3.   

    因为索引太多可能对insert性能影响比较大。
      

  4.   

    filed4 中有多少不同的值?
    filed5 ???然后再看 不同值最多,分布均匀的之后是哪个? 依据这个来平衡所需要创建的复合索引。
    建议你还是
    否则估计你还是继续问下去。解释起来比较复杂,帮助手册中讲了几千字。
      

  5.   

    把对应查找的字段建索引。配置文件中调整一下innodb_buffer_pool_size = 256M innodb_additional_mem_pool_size = 20M ,要是内存足够可以调大一点,配置文件中的参数是根据实际情况不断调整得到的,所以你还是要慢慢的调整观察。另外,考虑调整下面这些参数 key_buffer = 384M
    max_allowed_packet = 10M
    table_cache = 256
    sort_buffer_size = 2M
    read_buffer_size = 2M
    read_rnd_buffer_size = 8M
      

  6.   

    你的主键是什么?你的group by的条件是什么简单来讲,你完全可以按你group by的条件去分库分表
      

  7.   

    创建复合索引
    (filed5,filed6)
    建议不要贴图,有时看不到,自然有忽略了。 象下面一样贴文本,这样别人也容易分析。
    mysql> show index from t1;
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
    | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
    | t1    |          0 | PRIMARY  |            1 | id          | A         |      499999 |     NULL | NULL   |      | BTREE      |         |
    +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
    1 row in set (0.25 sec)mysql>
      

  8.   

    太专业啦。太强啦。我的qq 923570482希望能认识下啊。另外为什么要(filed5,filed6) 创建复合索引啊
      

  9.   

    为什么要(filed5,filed6) 创建复合索引啊
    http://dev.mysql.com/doc/refman/5.1/zh/optimization.html
    7. 优化
    7.1. 优化概述
    7.1.1. MySQL设计局限与折衷
    7.1.2. 为可移植性设计应用程序
    7.1.3. 我们已将MySQL用在何处?
    7.1.4. MySQL基准套件
    7.1.5. 使用自己的基准
    7.2. 优化SELECT语句和其它查询
    7.2.1. EXPLAIN语法(获取SELECT相关信息)
    7.2.2. 估计查询性能
    7.2.3. SELECT查询的速度
    7.2.4. MySQL怎样优化WHERE子句
    7.2.5. 范围优化
    7.2.6. 索引合并优化
      

  10.   

    1 可以考虑按天分库分表。时间建索引。
      如果是查询,则必须指定时间范围。如果跨多天,可以使用Union,必须确保使用了索引。
      当然,如果时间跨度太大,索引会失效。索引查询的数据量不能超过总数据量的30%。2 可以考虑搭建主备机制,采用多台备机,分担查询压力。保障主备不延迟即可。3 优化查询需求。确认这些查询是否必须实时查询出来不可?
      如果不是一定需要实时,可以定期跑出数据,放在一个结果集里。前台只需要查询这个结果集。4 如果一定要跨天查询。每天夜间,对前一天的数据进行预处理。使得查询可以在预处理后的数据基础上查询。避免事实查多次。5 数据库不能解决所有的问题,必须结合应用进行优化。最好的版本就是分表,预处理查询结果。
      

  11.   

    针对你的SQL语句与表的优化就不说了,我建议你分区或者分表,具体可以按照日期来分,结合你的业务,也可以有其他的优化方法。
    另外你的SQL语句不太合理。或者说太不合理。
    比如你那么多WHERE条件的组合,我认为可以分切为联合查询或者子查询吧,
    而limit的使用,这样用就彻底错了,虽然可以给你正确的结果,但mysql是以遍历了你的查询结果集做到的,
    limit建立你应子查询来实现。