避免使用count(*)获得表的记录数，解决其延迟问题

今天遇到这样一个细节问题，有个同事为了提高SQL执行效率使用sysindexes.rows来快速的计算表的行数

结果发现取出来的行数根本就不是实际表中的行数

就好比这样

为了获得表中的记录数，一般都使用下面的SQL语句：

　SELECT COUNT(*) FROM dbo.orders

但这条语句会执行全表扫描才能获得行数。

　下面的SQL语句不会执行全表扫描一样可以获得行数：

SELECT rows FROM sysindexes

　　WHERE id = OBJECT_ID('表名') AND indid < 2

网上很多优化文章都推荐这种做法，无可厚非，这种计算 sysindexes 中的rows，确实比计算实际表中的行数快。

但是由于像刚才那样发生问题的情况不多所以很容易被人们所忽略其实sysindexes 是以延迟的方式更新，rows计数可能会不准确

 

下面就是我用两种方法获取同一个表的行数所返回的值

 

 

可以清楚的看到两组返回值并不一致

 不细心的人由此可闹出不少笑话

 

 

接下来给出解决这种延迟问题的方法：

在查询分析器里面执行 DBCC UPDATEUSAGE(0, orders) with COUNT_ROWS

 使用DBCC UPDATEUSAGE报告sysindexes中的页数和行数错误并进行更正

0:表示当前数据库，

orders:需要进行报告和更正的表

COUNT_ROWS:指定使用表或视图中的行数的当前计数更新 row count 列

DBCC UPDATEUSAGE应用有很多，本文没做深挖

感兴趣的朋友可查阅更多相关资料

执行完毕后提示

---------------------------------------------------------------------

DBCC UPDATEUSAGE: 已更新表 orders的 sysindexes 行(索引 'PK_PND_ORDERS'，分区 1):

        行计数: 已从(7775)行更改为(7849)行。

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

---------------------------------------------------------------------

这时就及时更新了sysindexes使其和实际表中的行数达到一致。

 

 好了，今天就到这里文章以实用为主，希望能对你有帮助