大数据量时的性能问题

[losenetway]

有一个表UserWorks,数据量达到2百万时
执行
select count(*) from UserWorks
时需要耗费
4分多钟,
机器是P4的,
有什么办法可以让它快点么?
最好是在15秒种以内.

[losenetway]

btw:我在表上建立了聚集索引.

[肥三]

两百万count一次就要4分钟，实在有点离谱了。
你的机器硬件配置怎么样？负荷是不是很大？执行时看看CPU、内存、磁盘IO的情况。

[younger_go]

Select rows from sysindexes where id=object_id(N'tablename') and indid<2

[rouqu]

UP

[ReViSion]

如果建立了聚集索引的话，完全可以用这个
Select rows from sysindexes where id=object_id(N'tablename') and indid<2

[zlp321002]

--try
select count(*) from UserWorks
OPTION (HASH JOIN)

[younger_go]

Select rows from sysindexes where id=object_id(N'tablename') and indid<2
该方法获取表的记录总数的速度非常快，在毫秒级就可以完成，相比select count(*) 要快上数万倍，但是
大家在运用该方法是一定要主要，该方法得到的表的总记录数不是一个精确值，原因是MS SQL 并不是实时更
新该字段的值，而是定时更新，当从实践来看该值和精确值一般误差不大，如果你希望快速的粗略估算表的
大小，建议你采用该方法。如果你希望得到精确值，那么请在执行上述语句前执行
DBCC UPDATEUSAGE(DatabaseName,[TABLENAME]) WITH ROW_COUNTS
强制更新该字段的值，但这样第一次更新
时会耗费大量的时间，这样做的效果和建有聚簇索引的表 select count (*) 效果相差不大，所以如果你希
望相对快速地得到精确的表的记录总数，那么你有两种选择，建聚簇索引或者先DBCC 再使用上述方法。

[zlp321002]

select count(1) from UserWorks
OPTION (HASH JOIN)

[rouqu]

关于建簇级索引为什么会快 我的理解是
簇级索引包括页面节点，所有的行数就是总有的索引个数 所以在拥有簇级索引的情况下直接扫描索引即可得到结果。

[losenetway]

Select rows from sysindexes where id=object_id(N'tablename') and indid<2 是快多了,
select count(1) from UserWorks
OPTION (HASH JOIN) 的就没有什么快了

可能是我的数据库 有问题吧

[gslrq]

建议你重建索引~~

[Teng_s2000]

select count(某一字段) from 表

[billywolf]

Select rows from sysindexes where id=object_id(N'tablename') and indid<2


有时间试试

[holym]

借鉴

[luoqun_ncs]

你的内存配置不够,至少要把所有的索引页cache起来.你看一个sql server实例的pf delta

[fiele]

索引 select count(1) from 表这样会快点