Почему SELECT COUNT (*) выполняет сканирование с кластерным индексом?

Question

У меня есть следующая таблица:

CREATE TABLE [dbo].[Addr](
    [Address] [char](34) NOT NULL, 
CONSTRAINT [PK_Addr] PRIMARY KEY CLUSTERED 
(
    [Address] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] 
) ON [PRIMARY] 

И я пытаюсь выполнить запрос:

SELECT COUNT(*) 
FROM Addr 

Когда таблица содержит около 8 миллионов записей, он был немедленно выполняющийся. Но теперь таблица содержит 21 миллион записей, а запрос выполняется очень медленно. Managemet студия показывает следующий предполагаемый план:

Скриншот из вкладки Storage (Свойства таблицы):

Я использую MSSQL 2008 Express 10.50.1617.0. Почему этот простой запрос имеет такой сложный план?

Answer 1

Этот план не является сложным. Чтобы подсчитать количество записей, движок должен сканировать всю таблицу, но поскольку есть кластерный индекс, он использует его. Без кластеризованного индекса thre будет Table Scan вместо Clustered Index Scan. Если у вас был некластеризованный индекс в любом столбце, оптимизатор, скорее всего, будет выбирать этот индекс для подсчета записей, а операция будет быстрее.