是这样的
做了一个采集购物站,在dx_gd_goods里存了2千万条数据,以类别建索引,在where后根类别ID,查询的时候,开始的时候有点慢,后面紧接着的几次查询速度还比较快,但是好景不长,后面又非常慢了,是非常的慢,慢得后面mysql都超时了,都查询不出来数据。用explan 看信息时,是用了索引的,查询type 为 range后来想分一区,以类别分区,分区后,开始的前7次8次查询速度还是非常快的,如果在接着查询,问题与上面一样,mysql超时了,都返回不了数据。
用explan 看信息时,是用到了分区的,查询type 为 all我的mysql版本 5.1;这种情况不知道我怎么解决啊,我现在是无解了。

解决方案 »

  1.   

    select count(g_id) as num from dx_gd_goods where t_id >= 100101000 and t_id<100102000 limit 1
    select * from dx_gd_goods where t_id >= 100101000 and t_id<100102000 limit 0,20
      

  2.   

    t_id有索引不? 引擎是什么
    这SQL应该不是很慢。
      

  3.   

    感觉像是分区惹的祸,t_id 建立索引后应该不会很慢.  自己可以多测试就知道了。
      

  4.   

    引擎:MyISAM
    t_id 没有索引,t_id 与商品ID是一个主键,应该不是索引的关系,等会我建一个索引试试吧。
      

  5.   

    ”最后查询不出来“  是什么意思? 
    你可以贴出explain select............................. ; 结果看看。
      

  6.   

    explain partitions select * ...把结构发出来看看
      

  7.   

    type是all,那么你的分区根本就没用上啊
      

  8.   

    type 是什么才用上了呢?
      

  9.   

    因为type是all说明遍历了表中所有的数据,所以分区理所当然就没用上了,建议把explain partitions...结果发出来参考下
      

  10.   

    t_id 没有
    如果有了
    那么type 就会变成 index
    刚才试了,但是我的问题还是没有解决。还是会出现查询越来越慢的情况。
      

  11.   

    这么大的数据量而且是用分类id做做分区,那么我认为你值得给t_id做个索引
      

  12.   

    加t_id加上index索引,如果数据量很大limit定位很后的话会挺慢的。
      

  13.   

    检查下,是不是查的慢的那次的sql语句并不是你给出来这种结构,例如没有where条件等,按理说一般这样做了是不会出现这种情况的
      

  14.   

    是这样的,我执行的永远的都是上面那二条结构的sql语句,只不过t_id的范围不一要而己(就是点分类,多点几下,越来越慢,那怕回头点以前很快的分类,也会变得很慢)。
      

  15.   

    我没有limit 后面的语句。都 是0,20 
      

  16.   

    加索引了没。SHOW INDEX FROM dx_gd_goods 
      

  17.   

    刚才细看了一下,到最后查不出来东西时,cpu的使用就是98%以上,然后硬盘灯一直红着,SQL语句一样,为什么后面会越来越慢。
      

  18.   

    以前一样的sql语句,但是这一次查不出来东西。cpu使用100%
      

  19.   

    t_id >= 100101000 and t_id<100102000应该在 t_id 上建立索引
    分区的话需要按 t_id 分
      

  20.   

    问题解决了,我的问题,一个隐性的sql执行了,这条语句执行一次要100秒 刷新一下页面就要执行一下,这条SQL,修改了一下条件,好了,感谢大家的帮肋。