Поглиблена стратегія індексування

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

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

ракции даних є складним заняттям Вам потрібно при цьому на довгий & час запустити Profiler і досліджувати кожен запит Це є ще однією причиною того, чому жодна промислова база даних не повинна проекту-Перевірено роваться без належного рівня абстракції даних

У першу чергу виявите процедури та запити, які здійснюють доступ до таблиці і формують схему даних, використовуючи матрицю CRUD (create, retrieve, update, delete) (рис 503) У наступному прикладі ми проаналізуємо таблицю OrderDetail і для спрощення завдання проаналізуємо тільки три фіктивні процедури

У наступній таблиці будуть використані наступні абревіатури: S – для відбираються стовпців О – для впорядкування по стовпці W – для посилань на стовпець в пропозиції WHERE, G – для групування по функції

Таблиця 503 Аналіз використання таблиці операціями 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

і

Наступним кроком є ​​проектування найменшої кількості індексів, які задовольняють вимогам таблиці Цей процес вимагає в першу чергу визначення кластеризованого індексу, а потім створення індексів для кожної процедури та запиту, здійснюють доступ до таблиці (табл 504) Числа на діаграмі вказують на порядкову позицію стовпця в індексі Включаються стовпці помічені символом I

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

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

Таблиця 504 План стратегії індексування таблиці

Стовпець 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 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*