解决方案 »

  1.   

    30w的数据,要66s?你们机器得多烂啊!
    我想知道的是:
    你们的endtime 以什么结构存储的?
    为什么你们要用like?为什么like 的前面要加”%“这样不走索引啊你们的endtime 不会是字符串吧!存的是日期的串联?像”2011-01-01 2011-02-01 2011-03-01“这样的?
      

  2.   

    endtime用的是datetime类型的,数据库是连接阿里云上的,我用to_days(endtime)>to_days(now())函数去算今日的也很慢很慢啊,我将like前面去掉“%”也用了66秒
      

  3.   

     g.tableid = ? 这个是干嘛的
      

  4.   

     g.tableid = ?   问号是带入参数信息在navicat上查的:有什么办法吗
      

  5.   

    如果存的时候把时间存成毫秒,也就是转话成13位的long型,然后加上个索引,查的时候可以查两个值之间的,岂不是比like要快好多?突发奇想,不知道是否能够满足你的要求
      

  6.   

    贴执行计划吧。tableid 的重复值是不是很多?
      

  7.   

    时间是datetime类型的,不是字符类型,tableid现在只有10个不重复的。为什么不用like只加where条件也还是那么慢呢?
      

  8.   

    select count(*) from Gamerecord g where g.tableid = ? and DATE(g.endtime) = '2014-09-26' ;
      

  9.   

    (1)where的条件如果基本都是不重复的,加索引
    (2)like的左边不能加%, 右边可以加%,左边加了不能用索引(当然如果业务要求一定要左右都有%那没办法)LZ你这个问题,建议就是把列改成日期型
      

  10.   

    select count(*) from Gamerecord g 
    where g.tableid = ? and g.endtime like '%2014-09-26%' ;
    like无优化余地,只能改写同等sql。
    select count(*) from Gamerecord g 
    where g.tableid = ? and  date(g.endtime)= 2014-09-26;
      

  11.   

    endtime>'2014-10-11',时间字段加这个%,不对的
      

  12.   


    select count(*) from Gamerecord g where g.tableid = ? and g.endtime >= '2014-09-26' and g.endtime <  '2014-09-27'   ;然后给endtime 加个索引。
    记得条件里用函数或者like都会导致索引不起作用。
      

  13.   

    嗯,有索引不加函数和like就很快了,g.endtime>='2014-09-26' 就可以查今天的了,因为只需查询今天的数据就可以,‘2014-09-26’是每天的日期参数,随着每天的日期而改变的,非常感谢!