查詢語句是: select count(1) from Table1

解决方案 »

  1.   


    SELECT COUNT(1) FROM Table1此查询需要扫描整个表,耗時跟表的大小成正比,资料量越大耗時越长查询完成时,会把结果丟到緩冲区,下一次访问就直接取从緩存取了,所以时间会快的多。
      

  2.   

    同意楼上,,
    但要是测试的话,把缓冲删除
    DBCC FREEPROCCACHE 
    从过程高速缓存中删除所有元素。 DBCC DROPCLEANBUFFERS 
    从缓冲池中删除所有清除缓冲区
      

  3.   

    我不用SELECT COUNT(1) FROM Table1,用Select * From T1 Where F1=Value ,結果只有一條記錄,也用了這麼長時間,如果我再用SELECT COUNT(1) FROM Table1時,只用0秒,這又是為什么呢,感覺那張數據表在休眠一樣。
      

  4.   


    Select * From T1 Where F1=Value 
    >>此语句若F1上没索引,也是需要扫描全表的。
      

  5.   

    Select * From T1 Where F1=Value 
    有其它的索引没用,要有F1上的索引
      

  6.   

    我这也经常有这样的情况,很简单的一条语句查了N长时间,这时偶就直接cancel掉不查了,但这样的情况很少。
    具体原因看看有没高手知道。
      

  7.   

    仅供参考:可能你所查询的表上建了不恰当的聚集索引。
    隔了很长时间,有聚集索引的列发生更新或有新行插入时,
    都会导致表数据的物理重排,那么先前缓存中的查询数据和select语句会失效。
    所以第一次查询很慢(不恰当的聚集索引),以后查询直接读缓存所以很快。
    但一段时间后数据发生了改变,使得这种情况重演。解决方法:调整你的聚集索引
      

  8.   

    有可能是表结构问题;
    这423K的数据也不会太慢;
    http://so.tourba.com/
      

  9.   

    重新建索引后,還是這樣的,不過,這個表以前用的是Datetime字段做為主鍵,這有沒有什么影響?
      

  10.   

    去掉聚集索引看看?一般不用Datetime字段做為主鍵,很低效。
      

  11.   

    誰能說說Datetime字段或Identity自動增長型做主鍵有什么區別?
      

  12.   

    我也說不清,可能是Datetime系統要轉化為Long型存放吧,不過我測試過,Datatime的性能是要差些.
      

  13.   

    --清空后,再测
    DBCC FREEPROCCACHE 
    DBCC DROPCLEANBUFFERS
      

  14.   


    对表经常操作update\insert\delete会产生索引碎片,针对这样的表通常一段时间整理或重建一次
    测语句需要清除缓冲区
      

  15.   

    我在原来的字段上重新建索引,还是这样,不过我现在加了一个自动增长字段,并做PK,看以后的情况怎样,现在是比较快,1s就OK
      

  16.   

    楼主如果想查共有多少笔记录的话,可以使用sp_spaceused 表名,true
    速度一下快很多
      

  17.   

    你的增長字段上建立了聚集索引了吧?做一个JOB,每天晚上定时rebuild一下整理碎片
      

  18.   

    ●聚集索引结构
    在SQL Server中,索引是按B+树结构来进行组织的。聚集索引的数据排列顺序与数据的物理排列顺序相同。
    ●聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致.
      聚集索引表记录的排列顺序与索引的排列顺序一致,优点是查询速度快,
      因为一旦具有第一个索引值的纪录被找到,具有连续索引值的记录也一定物理的紧跟其后。
      聚集索引的缺点是对表进行修改速度较慢,这是为了保持表中的记录的物理顺序与索引的顺序一致,  
      而把记录插入到数据页的相应位置,必须在数据页中进行数据重排,降低了执行速度。
      建议使用聚集索引的场合为:
          ①此列包含有限数目的不同值;  
        ②查询的结果返回一个区间的值;  
        ③查询的结果返回某值相同的大量结果集。  
    ●非聚集索引指定了表中记录的逻辑顺序,但记录的物理顺序和索引的顺序不一致,
      聚集索引和非聚集索引都采用了B+树的结构,但非聚集索引的叶子层并不与实际的数据页相重叠,
      而采用叶子层包含一个指向表中的记录在数据页中的指针的方式。非聚集索引比聚集索引层次多,
      添加记录不会引起数据顺序的重组.  
      建议使用非聚集索引的场合为:
        ①此列包含了大量数目不同的值;  
        ②查询的结束返回的是少量的结果集;  
        ③WHERE字句用经常使用的列。
        ④经常需要连接或分组的列。  
        ⑤order   by   子句中使用了该列。  
      

  19.   

    数据库索引聚集索引:聚集索引规定数据在表中的物理存储顺序,因此一个表只能包含一个聚集索引,但该索引可以包含多个列(组合索引)对经常搜索的列建立聚集索引注意事项定义聚集索引键时使用的列越少越好,这一点很重要。如果定义了一个大型的聚集索引键,则同一个表上定义的任何非聚集索引都将增大许多,因为非聚集索引条目包含聚集键。在创建聚集索引之前,应先了解您的数据是如何被访问的。可考虑将聚集索引用于: 包含大量非重复值的列。使用下列运算符返回一个范围值的查询:BETWEEN、>、>=、< 和 <=。被连续访问的列。返回大型结果集的查询。经常被使用联接或 GROUP BY 子句的查询访问的列;一般来说,这些是外键列。对 ORDER BY 或 GROUP BY 子句中指定的列进行索引,可以使 SQL Server 不必对数据进行排序,因为这些行已经排序。这样可以提高查询性能。OLTP 类型的应用程序,这些程序要求进行非常快速的单行查找(一般通过主键)。应在主键上创建聚集索引。 
    聚集索引不适用于: 频繁更改的列 
    这将导致整行移动(因为 SQL Server 必须按物理顺序保留行中的数据值)。这一点要特别注意,因为在大数据量事务处理系统中数据是易失的。宽键 
    来自聚集索引的键值由所有非聚集索引作为查找键使用,因此存储在每个非聚集索引的叶条目内。非聚集索引:对于非聚集索引,可以为在表中查找数据时常用的每个列创建一个非聚集索引。在创建非聚集索引之前,应先了解您的数据是如何被访问的。可考虑将非聚集索引用于: 包含大量非重复值的列,如姓氏和名字的组合(如果聚集索引用于其它列)。如果只有很少的非重复值,如只有 1 和 0,则大多数查询将不使用索引,因为此时表扫描通常更有效。不返回大型结果集的查询。返回精确匹配的查询的搜索条件(WHERE 子句)中经常使用的列。经常需要联接和分组的决策支持系统应用程序。应在联接和分组操作中使用的列上创建多个非聚集索引,在任何外键列上创建一个聚集索引。在特定的查询中覆盖一个表中的所有列。这将完全消除对表或聚集索引的访问。 
    填充因子:
    创建索引时,可以指定一个填充因子,以便在索引的每个叶级页上留出额外的间隙和保留一定百分比的空间,供将来表的数据存储容量进行扩充和减少页拆分的可能性。填充因子的值是从 0 到 100 的百分比数值,指定在创建索引后对数据页的填充比例。值为 100 时表示页将填满,所留出的存储空间量最小。值越小则数据页上的空闲空间越大。说明:即使对于一个面向许多插入和更新操作的应用程序来说,数据库读取次数一般也超过数据库写入次数的 5 到 10 倍。因此,指定一个不同于默认设置的填充因子会降低数据库的读取性能,而降低量与填充因子设置值成反比。例如,当填充因子的值为 50% 时,数据库的读取性能会降低两倍。