解决方案 »

  1.   

    这个恐怕还是看你具体的设计以及具体的查询吧,单单说优化,范围太大了
    单表7000W也不算多吧,
    前段时间泄露出来的2000W开房信息,我虚拟机才1G内存1颗CPU,根据查询建了几个索引,也不觉得慢
      

  2.   


    我就说一下问题吧,查询的时候以where layerid='***' and time > '**8' and time <'***'为主,就是我先要找某层的(每个楼都有自己独立编号的层),某段时间的数据出来,我想问下,建立索引的话我这个怎么建立?目前我是layerid建立的聚集索引,time是非聚集索引?有什么不妥吗?
      

  3.   


    现在就最基本的要求,数据入库的时候不至于太慢,查询是以层号和时间共同来筛选的。
    目前服务器16G内存,我设置了最高2G内存使用。layerid建立的聚集索引,time是非聚集索引,不知道有什么地方有不对的?现在入库的时候偶尔会超时,查询速度有些慢。
      

  4.   

    A)给的内存太少,不要吝啬,数据库单独一台服务器,内存不限制。
    B)要(layerid,time)一起建聚集索引。
    如果没有单独按time查询的需求,那么单个的(time)索引毫无用处。
      

  5.   

    这个可以在LAYERID,TIME 上建联合聚集索引。 应该TIME 在前面。这样产生的碎片较少。个人看法啊
      

  6.   

    第一:layerid,聚集索引是对的。
    第二:time字段如果要加索引,那得看这个字段是精确到天的,还是到秒的。如果只是到天的。加索引可以;精确到秒的,加索引,不但起不到加快的效果 ,反而会变慢。
    第三:楼主的time条件,是需要到天还是到小时?如果要到小时,那么最好,把time字段拆开,一个只是短日期,另一个存小时,不会再到秒了吧?这样,在日期,小时字段上加索引,才有意义。