select count(*) from tab1 要11秒以上指示！！！？？？

Question

表有主键吗？把select count(*) from tab1 换成select count(主键列) from tab1 就好了。

Answer 1

select count(1) from tab1

Answer 2

libin_ftsafe(子陌红尘：当libin告别ftsafe) ( ) 只能重建表了吗？是表损坏了？tomhuang(春城) ( ) 和 billhepeng(过路客) ( )  
你们的提议没用，效果是一样的。而且我要不是做这个count的快慢，现在明显是'表'有问题

Answer 3

DBCC CHECKTABLE ('tbname')

Answer 4

DBCC CHECKTABLE看看是否有错误然后DBCC SHOWCONTIG看看这个表是否有索引碎片，如果碎片很严重，使用DBCC INDEXDEFRAG整理碎片

Answer 5

select rows from sysindexes where id = object_id('tab1') and indid < 2

Answer 6

DBCC CHECKTABLE 没发现有错误DBCC SHOWCONTIG:
DBCC SHOWCONTIG scanning 'tab1' table...
Table: 'tab1' (98099390); index ID: 1, database ID: 7
TABLE level scan performed.
- Pages Scanned................................: 1252730
- Extents Scanned..............................: 156851
- Extent Switches..............................: 156854
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.83% [156592:156855]
- Logical Scan Fragmentation ..................: 0.01%
- Extent Scan Fragmentation ...................: 12.22%
- Avg. Bytes Free per Page.....................: 7219.0
- Avg. Page Density (full).....................: 10.81%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.请问这样的结果正常吧？

Answer 7

DBCC SHOWCONTIG的结果还好看看执行计划，是否用到了聚集索引

Answer 8

有聚集索引: 自动编号 ID - int

Answer 9

数据库文件放在cluster上的,log和data文件不同分区上,硬盘dell检查过正常的.
我现在想重建表,这个表关系着三个表,就是有外键.
如果新建好表后,数据导回来前是不是要拿掉外键?这个自动编号的ID导入前关闭自动编号,导回数据后再设成自动编号会不会有影响?

Answer 10

同意luoqun_ncs(暂时冰封)所说。碰到问题不要急着想办法避开，找找原因先。

Answer 11

select count(*) from tb1
select count(*) from 另一个表比较一下他俩的执行计划和成本
比较一下他俩估计的执行计划和成本

Answer 12

关注.
1100多W,如果没有预读过,count一下要多久?谁能告诉我?

Answer 13

请大家再帮忙分析以下数据:
tab1在实时数据库上的Execution plan:
Estimated Row Count: 11898302
Estimated Row Size: 37
Estimated I/O cost: 151
Estimated CPU cost: 6.54
Estimated Number of executes: 1.0
Estimated cost: 157.083910 (100%)
Estimated Subtree cost: 157tab1在同步数据库上的Execution plan:
Estimated Row Count: 11898302
Estimated Row Size: 37
Estimated I/O cost: 16.4
Estimated CPU cost: 6.54
Estimated Number of executes: 1.0
Estimated cost: 22.944778 (97%)
Estimated Subtree cost: 22.9I/O Cost 差异?????

Answer 14

表碎片的问题，用dbcc shrinkdatabase(dbname)試一下

Answer 15

晕，重建一下索引，
DBCC DBREINDEX

Answer 16

使用 sp_spaceused tablename 返回值有 rows

Answer 17

msmis() :
再选择那些重复记录比较多得作为聚集索引，效果就会很好//恰恰相反,效果会很差的;如果某个字段只有0\1这2个值,1千万数据,效率相当差

Answer 18

LZ,I如果索引确实重新建过,I/O差距这么大,估计和服务器的硬件配置有关系了再试试
在实时数据库新建一个数据库,把千万数据重新组织成一个新表,再看看count的效率;

Answer 19

问题就在索引上
有问题的表：DBCC SHOWCONTIG 
 Avg. Page Density (full).....................: 10.81%
--平均页的密度才10%
你同步表的DBCC SHOWCONTIG 信息呢？

Answer 20

同步表的DBCC SHOWCONTIG 信息:
DBCC SHOWCONTIG scanning 'tab1' table...
Table: 'tab1' (98099390); index ID: 1, database ID: 7
TABLE level scan performed.
- Pages Scanned................................: 152871
- Extents Scanned..............................: 19178
- Extent Switches..............................: 19219
- Avg. Pages per Extent........................: 8.0
- Scan Density [Best Count:Actual Count].......: 99.42% [19109:19220]
- Logical Scan Fragmentation ..................: 0.09%
- Extent Scan Fragmentation ...................: 13.13%
- Avg. Bytes Free per Page.....................: 55.8
- Avg. Page Density (full).....................: 99.31%
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Answer 21

问题很明显了，
有问题的表:
- Pages Scanned................................: 1252730
同步表：
- Pages Scanned................................: 152871
8倍的数据页感觉还是填充因子的问题，别的问题想不到了

Answer 22

select count(1) from td要有主键