SQL性能低下

Question

我的查询如下;

 SELECT COUNT(Id) FROM Table

该表包含3300万条记录 - 它包含Id上的主键,没有其他索引.

查询需要30秒.

实际执行计划显示它使用聚簇索引扫描.

我们已经分析了该表,发现它没有使用此链接中显示的第一个查询进行分段:http://sqlserverpedia.com/wiki/Index_Maintenance.

关于为什么这个查询如此缓慢以及如何解决它的任何想法.

表定义:

 CREATE TABLE [dbo].[DbConversation](
[ConversationID] [int] IDENTITY(1,1) NOT NULL,
[ConversationGroupID] [int] NOT NULL,
[InsideIP] [uniqueidentifier] NOT NULL,
[OutsideIP] [uniqueidentifier] NOT NULL,
[ServerPort] [int] NOT NULL,
[BytesOutbound] [bigint] NOT NULL,
[BytesInbound] [bigint] NOT NULL,
[ServerOutside] [bit] NOT NULL,
[LastFlowTime] [datetime] NOT NULL,
[LastClientPort] [int] NOT NULL,
[Protocol] [tinyint] NOT NULL,
[TypeOfService] [tinyint] NOT NULL,
  CONSTRAINT [PK_Conversation_1] PRIMARY KEY CLUSTERED 
 (
[ConversationID] ASC
 )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
 ) ON [PRIMARY]
 GO

我注意到的一件事是数据库设置为以1Mb块增长.

这是一个现场系统,因此我们限制了我们可以玩的东西 - 任何想法？

更新:

好的 - 我们通过在适当的列上添加新的非聚集索引来提高实际感兴趣的查询的性能,因此它不再是一个关键问题.

SELECT COUNT 虽然仍然很慢 - 尝试使用NOLOCK提示 - 没有区别.

我们都认为这与设置为1Mb的Autogrowth而不是更大的数字有关,但令人惊讶的是它具有这种效果.磁盘上的MDF碎片可能是可能的原因吗？

Answer 1

这是一个经常读/插/更新的表吗？是否有与您的选择并发的更新/插入活动？

我的猜测是延迟是由于争用.

我能够在我的开发服务器上在17秒内运行189m行的计数,但没有其他任何东西击中该表.

如果您不太担心争用或绝对准确性,您可以这样做:

exec sp_spaceused 'MyTableName' 这将根据元数据进行计数.

如果您想要更准确的计数,但不一定关心它是否反映并发DELETE或INSERT活动,您可以使用NOLOCK提示执行当前查询:

SELECT COUNT(id) FROM MyTable WITH (NOLOCK) 它不会获得您的查询的行级锁定,应该运行得更快.