Главная » Microsoft SQL Server, Базы данных » Углубленная стратегия индексирования

0

Стратегия индексирования имеет дело с крупными задачами, а не с изолированными ситуациями, способными нанести ущерб общему процессу. При выполнении аудита фактической производительности оказывается, что наиболее частыми проблемами индексирования являются (в порядке важности) отсутствие индексов и лишние, ненужные индексы. Именно поэтому лучше тратить время на индексирование на основе таблиц, а не отдельных запросов.

А      Разработка стратегии индексирования без наличия полноценного уровня абст-

ракции данных является сложным занятием. Вам нужно при этом на долгое &время запустить Profiler и исследовать каждый запрос. Это является еще одной причиной того, почему ни одна промышленная база данных не должна проекти- Проверено роваться без надлежащего уровня абстракции данных.

В первую очередь выявите процедуры и запросы, которые осуществляют доступ к таблице и формируют схему данных, используя матрицу CRUD (create, retrieve, update, delete) (рис. 50.3). В следующем примере мы проанализируем таблицу OrderDetail и для упрощения задачи проанализируем только три фиктивные процедуры.

В следующей таблице будут использованы следующие аббревиатуры: S — для отбираемых столбцов; О — для упорядочения по столбцу; W — для ссылок на столбец в предложении WHERE, G — для группировки по функции.

Таблица 50.3. Анализ использования таблицы операциями CRUD

Столбец

pGetOrder

pCheckQuantity pShipOrder

OrderDetaillD

S

w

OrderlD

w

w

ProductID

s

s

NonStockProduct

s

Quantity

s

s

UnitPrice

s

ExtendedPrice

s

ShipRequestDate

s

w

ShipDate

s

и

ShipComment

s

и

Следующим шагом является проектирование наименьшего количества индексов, которые удовлетворяют требованиям таблицы. Этот процесс требует в первую очередь определения кластеризованного индекса, а затем создания индексов для каждой процедуры и запроса, осуществляющих доступ к таблице (табл. 50.4). Числа на диаграмме указывают на порядковую позицию столбца в индексе. Включаемые столбцы помечены символом I.

Так как таблица OrderDetail часто опрашивается с использованием столбца OrderlD и этот столбец может также быть использован для объединения множества строк на одной странице данных, он является лучшим кандидатом на кластеризованный индекс (CI). Данный кластеризованный индекс состоит из одного столбца OrderlD, на что указывает единица в первом столбце.

Данный кластеризованный индекс удовлетворяет процедуре pGetOrder.

Таблица 50.4. План стратегии индексирования таблицы

Столбец CI

1×1

1×2

OrderDetailID

l

OrderlD 1

(cl)

(cl)

ProductID

I

NonStockProduct

Quantity

I

UnitPrice

ExtendedPrice

ShipRequestDate

1

ShipDate

ShipComment

Процедура pShipQuantity проверяет количество товаров в наличии перед доставкой и фильтрует строки по столбцам ShipRequestDate и OrderlD. Создание непастеризованного индекса по ShipRequestDate приведет к использованию в этом индексе обоих столбцов: ShipRequestDate и OrderlD. Это связано с тем, что кластеризованный индекс всегда присутствует в листовых узлах некластеризованного индекса. Поскольку данной процедуре нужны всего четыре столбца, добавление в индекс в качестве включаемых столбцов ProductID и Quantity позволит индексу 1×1 полностью покрыть потребности запроса и существенно повысить производительность.

Третья процедура может удовлетвориться добавлением некластеризованного индекса 1×2 на основе столбца OrderDetail ID.

Хотя в данном примере мы рассматривали всего три процедуры, в производственной таблице их будет больше, и некоторые индексы смогут покрыть потребности одновременно нескольких процедур.

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии