Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
← Октябрь 2004 → | ||||||
2
|
3
|
|||||
---|---|---|---|---|---|---|
4
|
5
|
6
|
8
|
9
|
10
|
|
11
|
12
|
13
|
14
|
16
|
17
|
|
18
|
19
|
20
|
21
|
22
|
23
|
|
25
|
26
|
27
|
28
|
29
|
30
|
31
|
Статистика
-20 за неделю
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#216<< #217 |
СОДЕРЖАНИЕ
Операции с большими объемами данных в SQL Server. Часть 2 (начало)
По материалам статьи
Joe Chang
Large Data Operations in SQL Server Запросы обновления Те же самые четыре типа запросов были протестированы для команды Update. Первая пара запросов обновляет последовательный блок из 100 000 строк. Вторая пара запросов обновляет 100 000 строк, где каждая строка находится в отдельной 8-килобайтной странице. Команда Checkpoint выполняется сразу после команды Update. Сложение времени выполнения команд Update и Checkpoint определяет действительное время, необходимое для записи изменений на диск. Даже если сессия Query Analyzer может показывать, что команда выполнена, сложение времени выполнения двух команд является более точной оценкой реальных затрат. -- Последовательные строки, поиск по индексу UPDATE m SET randMoney = 1.0 FROM M3C_01 m WHERE SeqID = 91 GO CHECKPOINT GO -- Последовательные строки, сканирование таблицы UPDATE m SET randMoney = 1.0 FROM M3C_01 m WITH(INDEX(0)) WHERE SeqID = 91 GO CHECKPOINT GO -- Разнесенные строки, поиск по индексу UPDATE M3C_01 SET randMoney = 5000.0 WHERE DistID = 91 GO CHECKPOINT GO -- Разнесенные строки, сканирование таблицы UPDATE m SET randMoney = 1.0 FROM M3C_01 m WITH(INDEX(0)) WHERE DistID = 5 GO CHECKPOINT GO План выполнения для первой пары команд Update показан ниже. Заметьте, что план без хинтов использует поиск по индексу, чтобы найти строки для обновления. Индекс может только определить строки для обновления, но не загружает в действительности страницу данных в память. Нигде не видно, что первый план действительно учитывает затраты на получение страницы данных, которую нужно изменить. Перед тем, как SQL Server сможет записать информацию на страницу, она сначала должна быть загружена в буферный кэш. Хинт INDEX(0) во втором плане - это указание на использование сканирования таблицы.
Index Seek требует таких же затрат, как и в запросе Select. Операции Top и Compute Scalar добавляют к загрузке процессора 0.010000 каждая. Операция Table Update требует 0.010068 затрат ввода-вывода и 0.100000 загрузки процессора, а также 0.0000001 затрат на строку. Как обсуждалось ранее, план выполнения показывает те же затраты ввода-вывода, несмотря на количество вовлеченных строк или страниц. Index Seek не может гарантировать, что строки обновляются по порядку.
Ниже показаны окна детализации команды Update, использующей хинт для сканирования таблицы. Данные детализации затрат на сканирование таблицы такие же, что и у команды Select. Здесь операция Top добавляет 4.809997 затрат, хотя даже затраты ввода-вывода и загрузка процессора - такие же, что и у предыдущей операции Update. Оператор Table Update имеет такую же структуру затрат в обоих случаях.
Конечный результат формул затрат плана выполнения состоит в том, что план по умолчанию, использующий поиск по индексу, менее затратен, чем план со сканированием таблицы в 238 раз. Такой результат получается полностью из-за разницы в затратах между поиском 100 000 строк по индексу высокой плотности и табличным сканированием 101 012 страниц и 10М строк. Следующая таблица показывает действительное время выполнения команды Update и следующей за ней Checkpoint для конфигураций памяти 256M и 1154M.
План выполнения с поиском по индексу действительно работает быстрее, когда все изменяемые строки находятся на соседних страницах, но он может работать гораздо медленнее, если изменяемые строки разнесены по многим страницам. Т.к. статистика SQL Server не может определить степень распределения изменяемых строк, то формула затрат плана выполнения не должна подразумевать, что строки находятся на смежных страницах. Нет никаких оснований ожидать, что строки из значения обычного некластерного индекса хранятся на соседних страницах. Однако SQL Server всегда выбирает план выполнения с поиском по индексу, если существует индекс на поисковом аргументе, т.к. план выполнения не учитывает затраты на получение страниц данных, также, как и операция Bookmark Lookup. Очевидно, что действительные затраты на самом деле также включают затраты на получение строки данных. Это расхождение может приводить к появлению очень медленного плана выполнения по сравнению с методом сканирования таблицы в случае отсутствия индексов. Простое изменение условия SET в запросе UPDATE на randMoney = randMoney + 1.0 даст в результате план, показанный ниже. Теперь план выполнения по умолчанию использует сканирование таблицы, а план выполнения с индексом на поисковом аргументе использует операцию bookmark lookup.
Запросы удаления Запросы удаления показаны ниже. Первые два запроса используют строки из последовательно расположенных страниц, а вторая пара использует строки, разнесенные по всем страницам, как это было в других примерах. -- Последовательные строки, поиск по индексу DELETE M3C_01 WHERE SeqID = 91 GO CHECKPOINT GO -- Последовательные строки, сканирование таблицы DELETE m FROM M3C_01 m WITH(INDEX(0)) WHERE SeqID = 71 GO CHECKPOINT GO -- Разнесенные строки, поиск по индексу DELETE M3C_01 WHERE DistID = 91 GO CHECKPOINT GO -- Разнесенные строки, сканирование таблицы DELETE m FROM M3C_01 m WITH(INDEX(0)) WHERE DistID = 27 GO CHECKPOINT GO Без хинтов план выполнения использует поиск по индексу. Затраты ввода-вывода на чтение страницы данных и строки не учитываются планом выполнения, таким же, как план выполнения команды Update. Использование запросом сканирования таблицы порождает гораздо более затратный план. После операции Table Delete производится операция Spool, после которой производятся операции Index Delete для двух индексов этой таблицы.
(Окончание следует) Статьи на русском языке
XP SP2 и SQL Server
Build a Delimited List And Query Syscomments, Tricks of the Trade Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
Расширение базы и группы файлов Теория и практика построения баз данных 9-е изд.
Практикум по технологиям баз данных. Учебное пособие
|
#216<< #217 |
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||