Медленный SQL производительность

У меня есть следующий запрос:

 SELECT COUNT(Id) FROM Table

Таблица содержит 33 миллиона записей - она ​​содержит первичный ключ по Id и никаких других индексов.

Запрос занимает 30 секунд.

фактический план выполнения показывает, что он использует сканирование кластерного индекса.

Мы проанализировали таблицу и обнаружили, что она не фрагментирована, используя первый запрос, показанный по этой ссылке: http://sqlserverpedia.com/wiki/Index_Main 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

Я заметил одну вещь: размер базы данных настроен на куски по 1 МБ.

Это живая система, поэтому мы ограничили то, с чем мы можем поиграть - какие-нибудь идеи?

ОБНОВЛЕНИЕ:

ОК - мы улучшили производительность в реальном интересующем запросе, добавив новые некластеризованные индексы в соответствующие столбцы, поэтому это уже не критическая проблема.

SELECT COUNT по-прежнему работает медленно - попробовал с подсказками NOLOCK - никакой разницы.

Мы все думаем, что это что-то, что нужно d o с Autogrowth, установленным на 1 МБ, а не на большее число, но удивлен, что у него есть такой эффект. Может ли фрагментация MDF на диске быть возможной причиной?