曾经考虑从业务上减小该表数据量,但是不符合需求。现状就是每天都有起码100w条数据进入这个表,
对这个表的操作倒是很简单,只是做一个select * from tabA a,tabB b where a.id = b.id;
的sql但是由于数据量太大做这个操作太慢了。不知道有没有什么办法啊。
表的字段也不多大概10个。优化,现在就只做了pk的index其他都没有做啊。
以前也听人说
什么垂直分割水平分割
什么用多个mysql集群只做查询用,insert另外做。什么的。现在思路就是想从mysql这块做点优化。
从表这块做点优化。
不知道有人能提供点优化办法吗?
解决了放500分啊。感谢大家乐很头疼555

解决方案 »

  1.   

    select * from tabA a,tabB b where a.id = b.id;主要的查询是这个SQL语句?什么where 条件都没有?
    如果这样,则没什么可优化的了。 两个表上的ID都有索引即可。操作慢是相对的,你可以试一下 select * from tabA; 和 select * from tabB; 
    select * from tabA a,tabB b where a.id = b.id;查询的速度再什么优化也不可能快于上面两个查询的时间总和。
      

  2.   

    假如这100W条数据写入了表A中,也就是tabA。
    那么:
    1.tabA,分割。按日期也好,还是按表中其他字段也好,请做一个分割。或者分区也好。
    2.按你的描述,tabB中的数据应该较少且相对稳定吧。那么将查询改为:
    SELECT * FROM tabB,tabA WHERE tabA.id=tabB.id;
    .用小表来驱动大表。
    3.是不是真的要'SELECT * '呢?就没有无用的字段吗?试着将tabA中的没有必要使用的字段不做查询你,减少IO量和数据传送量。将tabA中的这些字段单独拿出去,作为一张新表,与tabA中记录一一对应,尽量减小tabA的体积。
    4.索引字段id。
    5.修改表的引擎为innodb引擎。这样可以避免表级锁的发生。
      

  3.   

    谢谢啊!
    1.tabA,分割。按日期也好,还是按表中其他字段也好,请做一个分割。或者分区也好。 
    这个怎么拆分啊?
    2.按你的描述,tabB中的数据应该较少且相对稳定吧。那么将查询改为:
    SQL codeSELECT*FROM tabB,tabAWHERE tabA.id=tabB.id;.用小表来驱动大表。
    意思就是from后面先是小表,然后是大表?
    3.是不是真的要'SELECT * '呢?就没有无用的字段吗?试着将tabA中的没有必要使用的字段不做查询你,减少IO量和数据传送量。将tabA中的这些字段单独拿出去,作为一张新表,与tabA中记录一一对应,尽量减小tabA的体积。
    确实没有无用的字段了。我知道用*会造成全表扫描
    4.索引字段id。
    这个建立过了
    5.修改表的引擎为innodb引擎。这样可以避免表级锁的发生。
    如果用innodb的话是不是会造成速度变慢啊?
      

  4.   


    回答:
    1.不可以按时间或者你的条件分区表,或者是水平分割为多个物理表。
    2.是的。涉及到笛卡尔乘积的速度。
    3.不用回答。
    4.不用回答。
    5.表面上看是会造成速度变慢,但仔细分析你会分先会提高速度。
      原因是:innodb是行级锁,不会在插入数据的时候或者读取数据的时候造成全表的锁定,而出现等待。
      

  5.   

    你的查询主要是什么? 如果连任何 where 子句都没有,也谈不上什么优化了。
      

  6.   

    1)表分割(分开多个表来进行存储,但此方法不一定适合你的业务)
    2)表分区(分开多个逻辑分区来存储,但MySQL版本一定要 5.1 或者以上)
    3)历史数据转移(此方法不一定适合全表查询)
    4)升级服务器
    5)考虑使用群集
    6)考虑是否转为其他数据;感觉到了处理千万级别数据时候,MySQL 无论在安全性和性能上都是大幅度下降。 
      

  7.   

    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 ?
    Sql基本都是这样的啊
      

  8.   

    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 ?
    Sql基本都是这样的啊
      

  9.   

    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 ?
      

  10.   

    1.首先应该调研一下用户的习惯,查询的频率多不多,时间范围主要集中是一天,一周还是一月内
      确定一下优化的程度,数量级到达一定层次 只能在硬件和架构上找了下面引ACMAIN_CHM,说的很对,如果感觉优化达不到目标,建议在架构上做改良
    [操作慢是相对的,你可以试一下 select * from tabA; 和 select * from tabB;
    select * from tabA a,tabB b where a.id = b.id;查询的速度再什么优化也不可能快于上面两个查询的时间总和。]2.建merge表加快插入 stime分区加速查询 建index加速查询(反之加速插入)
    3.如果这个时间仍不行
      

  11.   




    limit ?
      

  12.   

    不知道mysql有没有物化视图的概念
      

  13.   


    好像mysql没有物化视图的概念
      

  14.   


    好像mysql没有物化视图的概念
      

  15.   


    好像mysql没有物化视图的概念