date是DATETIME类型,索引基本没用。
TYPE是什么类型的?可以考虑在这个做个索引。
历史数据迁移也是很必要的。

解决方案 »

  1.   

    把id作为主键 作为标识列 索引也建立在ID上就OK了
      

  2.   

    几种情况:
    1、如果date,type这两个条件是一起的,即大部分情况这两个条件是必须的,建立联合索引(date,type)
    2、如果date,type这两个条件是独立的,即大部分情况这两个条件可以选一个,或者两个都选,建立两个索引(date),(type)
      

  3.   

    表的主键、外键必须有索引;2、数据量超过300的表应该有索引;3、经常与其他表进行连接的表,在连接字段上应该建立索引;4、经常出现在Where子句中的字段,特别是大表的字段,应该建立索引;5、索引应该建在选择性高的字段上;6、索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建索引;7、复合索引的建立需要进行仔细分析;尽量考虑用单字段索引代替:   A、正确选择复合索引中的主列字段,一般是选择性较好的字段;   B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中?单字段查询是否极少甚至没有?如果是,则可以建立复合索引;否则考虑单字段索引;   C、如果复合索引中包含的字段经常单独出现在Where子句中,则分解为多个单字段索引;   D、如果复合索引所包含的字段超过3个,那么仔细考虑其必要性,考虑减少复合的字段;   E、如果既有单字段索引,又有这几个字段上的复合索引,一般可以删除复合索引;8、频繁进行数据操作的表,不要建立太多的索引;9、删除无用的索引,避免对执行计划造成负面影响;   以上是一些普遍的建立索引时的判断依据。一言以蔽之,索引的建立必须慎重,对每个索引的必要性都应该经过仔细分析,要有建立的依据。因为太多的索引与不充分、不正确的索引对性能都毫无益处:在表上建立的每个索引都会增加存储开销,索引对于插入、删除、更新操作也会增加处理上的开销。另外,过多的复合索引,在有单字段索引的情况下,一般都是没有存在价值的;相反,还会降低数据增加删除时的性能,特别是对频繁更新的表来说,负面影响更大。
      

  4.   

    CREATE  INDEX 索引名 ON 表名([date], [type]) ON [PRIMARY]
      

  5.   

    动作描述                使用聚集索引   使用非聚集索引 
    外键列                       应            应 
    主键列                       应            应 
    列经常被分组排序(order by) 应            应 
    返回某范围内的数据           应          不应 
    小数目的不同值               应           不应 
    大数目的不同值             不应            应 
    频繁更新的列               不应           应 
    频繁修改索引列             不应           应 
    一个或极少不同值           不应          不应 
      

  6.   

    以上两个条件是一起使用的 type是varchar类型历史数据迁移,我选择在晚上,数据库比较闲的时候操作,这样成本应该不会很高,其实我查询也不常做,但是对每次操作要求要非常快,数据平时都是在内存进行查询,只有重起或缓存过期才会使用到数据库