select count(*) from tab1 要11秒以上指示！！！？？？
现在应用程序做任何录入、查询都很慢。
暂时发现这样一个问题：
tab1里有1千1百万多记录.在服务器(dell3950)上用查询分析做以上查询用时超过11秒!!，而另一个表1千8百多万记录做这样的查询用时不到2秒。
而在这个数据库同步的服务器上数据库对该表做这样的查询用时不到2秒！！
已经对该表重建过索引了，请各位大虾帮忙。急啊！！！

[解决办法]
重建表...
[解决办法]
对海量数据检索,性能上的损失是必然的.否则各大论坛网站不会分开检索:前年的,去年的,今年的.那是在调不同的表.或数据库.

1千1百万条记录,可以考虑拆分数据,把旧的数据作备用使了.
[解决办法]
表有主键吗？把select count(*) from tab1 换成select count(主键列) from tab1 就好了。
[解决办法]
select count(1) from tab1
[解决办法]
DBCC CHECKTABLE ( 'tbname ')

[解决办法]
DBCC CHECKTABLE看看是否有错误

然后DBCC SHOWCONTIG看看这个表是否有索引碎片，如果碎片很严重，使用DBCC INDEXDEFRAG整理碎片
[解决办法]
select rows from sysindexes where id = object_id( 'tab1 ') and indid < 2
[解决办法]
DBCC SHOWCONTIG的结果还好

看看执行计划，是否用到了聚集索引
[解决办法]
把表拆成多表吧，弄分区视图
[解决办法]
to楼上，碰到问题不要急着想办法避开，找找原因先。分区不是仙丹，分区是用来解决这个问题的么？

楼主，比较在两个数据库中的执行计划，既然你已经重建了索引，我相信你的索引参数都是一样的（主要是填充率）。如果还是不行，我怀疑是你这个表所在的磁盘有问题。
[解决办法]
同意luoqun_ncs(暂时冰封)所说。

碰到问题不要急着想办法避开，找找原因先。
[解决办法]
select count(*) from tb1
select count(*) from 另一个表

比较一下他俩的执行计划和成本
比较一下他俩估计的执行计划和成本
[解决办法]

关注.
1100多W,如果没有预读过,count一下要多久?谁能告诉我?
[解决办法]
聚集索引 不能建立在自动编号上。
如果自动编号是主建，那么系统会自动建立聚集索引，做法就是把这个去掉，再选择那些重复记录比较多得作为聚集索引，效果就会很好

[解决办法]
表碎片的问题，用dbcc shrinkdatabase(dbname)一下
[解决办法]
晕，重建一下索引，
DBCC DBREINDEX
[解决办法]
使用 sp_spaceused tablename 返回值有 rows

[解决办法]
msmis() :
再选择那些重复记录比较多得作为聚集索引，效果就会很好

//恰恰相反,效果会很差的;如果某个字段只有0\1这2个值,1千万数据,效率相当差
[解决办法]
LZ,I如果索引确实重新建过,I/O差距这么大,估计和服务器的硬件配置有关系了

再试试
在实时数据库新建一个数据库,把千万数据重新组织成一个新表,再看看count的效率;
[解决办法]
你的聚集索引的填充因子是多少？
同步的服务器上这个表的填充因子是多少？
[解决办法]
问题就在索引上
有问题的表：DBCC SHOWCONTIG
Avg. Page Density (full).....................: 10.81%
--平均页的密度才10%
你同步表的DBCC SHOWCONTIG 信息呢？
[解决办法]
问题很明显了，

有问题的表:
- Pages Scanned................................: 1252730
同步表：
- Pages Scanned................................: 152871
8倍的数据页

感觉还是填充因子的问题，别的问题想不到了

[解决办法]
高手在议论,我来mark
[解决办法]
索引建的有问题
[解决办法]
select count(1) from td

要有主键