My<cod/>.net
В чем разница между сканированием таблиц и сканированием кластеризованных индексов?
Поскольку и A Table Scan , и a Clustered Index Scan по существу сканируют все записи в таблице, почему Кластеризованное сканирование индекса предположительно лучше?
В качестве примера-какова разница в производительности между следующими, когда есть много записей?:
declare @temp table(
SomeColumn varchar(50)
)
insert into @temp
select 'SomeVal'
select * from @temp
-----------------------------
declare @temp table(
RowID int not null identity(1,1) primary key,
SomeColumn varchar(50)
)
insert into @temp
select 'SomeVal'
select * from @temp
В таблице без кластеризованного индекса (таблица кучи) страницы данных не связаны между собой, поэтому для обхода страниц требуется поиск в карте распределения индекса .
Однако кластеризованная таблица имеет свои страницы данных, связанные в двусвязном списке , что делает последовательное сканирование немного быстрее. Конечно, в обмен на это у вас есть накладные расходы , связанные с сохранением страниц данных в порядке на INSERT , UPDATE и DELETE . Однако для таблицы кучи требуется вторая запись в IAM.
Если ваш запрос содержит оператор RANGE (например, SELECT * FROM TABLE WHERE Id BETWEEN 1 AND 100), то кластеризованная таблица (находящаяся в гарантированном порядке) будет более эффективной, поскольку она может использовать страницы индекса для поиска соответствующих страниц данных. Куча должна была бы сканировать все строки, так как она не может полагаться на порядок.
И, конечно же, кластеризованный индекс позволяет выполнять поиск кластеризованного индекса, что в значительной степени оптимально для кучи performance...a без индексов всегда приведет к сканированию таблицы.
Так:
Для вашего примера запроса, в котором вы выбираете все строки, единственным отличием является двусвязный список, поддерживаемый кластеризованным индексом. Это должно сделать вашу кластеризованную таблицу чуть быстрее, чем кучу с большим количеством строк.
Для запроса с предложением
WHERE, который может быть (по крайней мере частично) удовлетворен кластеризованным индексом, вы выйдете вперед из - за упорядочивания-так что вам не придется сканировать всю таблицу.Для запроса, который не насыщен кластеризованным индексом, вы в значительной степени even...again, единственное отличие-это двусвязный список для последовательного сканирования. В любом случае, вы неоптимальны.
Для
INSERT,UPDATEиDELETEкуча может выиграть, а может и не выиграть. Куча не должна поддерживать порядок, но требует второй записи в IAM. Я думаю, что относительная разница в производительности будет незначительной, но также довольно сильно зависит от данных.
У Microsoft есть технический документ, который сравнивает кластеризованный индекс с эквивалентным некластеризованным индексом в куче (не совсем так, как я обсуждал выше, но близко). Их вывод заключается в основном в том, чтобы поместить кластеризованный индекс на все таблицы. Я постараюсь суммировать их результаты (опять же, обратите внимание, что они действительно сравнивают некластеризованный индекс с кластеризованным индексом здесь - но я думаю, что это относительно сопоставимо):
- Производительность
INSERT: кластеризованный индекс выигрывает примерно на 3% из-за второй записи, необходимой для кучи. - Производительность
UPDATE: кластеризованный индекс выигрывает примерно на 8% из-за второго поиска, необходимого для кучи. - Производительность
DELETE: кластеризованный индекс выигрывает примерно на 18% из-за необходимости второго поиска и второго удаления из IAM для кучи. - single
SELECTperformance: кластеризованный индекс выигрывает примерно на 16% из-за второго поиска, необходимого для кучи. - диапазон производительности
SELECT: кластеризованный индекс выигрывает примерно на 29% из-за случайного упорядочения кучи. - параллельный
INSERT: таблица кучи выигрывает 30% при загрузке из-за разбиения страниц для кластеризованного индекса.
http://msdn.microsoft.com/en-us/library/aa216840(SQL.80).aspx
Оператор Clustered Index Scan logical and physical сканирует кластеризованный индекс, указанный в столбце Argument. При наличии необязательного предиката WHERE:() возвращаются только те строки, которые удовлетворяют этому предикату. Если столбец аргумента содержит предложение ORDERED, обработчик запросов запросил, чтобы выходные данные строк возвращались в том порядке, в котором кластеризованный индекс их отсортировал. Если предложение ORDERED отсутствует, механизм хранения будет сканировать индекс оптимальным образом (не гарантируя сортировку выходных данных).
http://msdn.microsoft.com/en-us/library/aa178416(SQL.80).aspx
Логический и физический оператор Table Scan извлекает все строки из таблицы, указанной в столбце Argument. Если в столбце аргумента появляется предикат WHERE:(), то возвращаются только те строки, которые удовлетворяют этому предикату.