Глобальний підхід до налаштування індексів

SQL являє собою описовий, декларативний мову Це означає, що запити SQL як би задають питання, a SQL Server самостійно вирішує, як на них відповісти Виходячи з цього, левова частка оптимізації виконується на рівні SQL Server, а не самих запитів

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

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

Налаштування індексів є навичкою, що вимагає глибокого розуміння декількох незалежних факторів Насправді настройку запитів ускладнює те, що сам оптимізатор запитів є чимось на зразок чорного ящика І перед тим як ви зможете передбачити його поведінку, ви повинні зрозуміти взаємозвязок наступних факторів

■ Сторінкова архітектура SQL Server, модель фізичної схеми і логічні оператори плану виконання запиту

■ Розподіл даних, статистика індексів, вибір індексів оптимізатором запитів і забезпечення обслуговування індексів

■ Кластеризувати структура індексів, коефіцієнт заповнення, злиття сторінок і обслуговування індексів

■ Запити, індекси, плани виконання запитів і оптимізатор запитів

■ Повторне використання плану запиту і застосування параметрів

Як розробник або адміністратор баз даних ви повинні розуміти, які індекси є кращими серед маси виробничих запитів, а не тільки одного запиту

Найкраще, що я можу порекомендувати, – це вивчити всі фактори, а потім провести власні експерименти, щоб зрозуміти всі складнощі кореляції між даними, схемою, індексами і запитами Коригування індексів не робить ніякого впливу на логічний результат будь-якого запиту Адміністраторам баз даних не слід боятися експериментувати з індексами

Індексація

Предметний покажчик допомагає читачам швидко знайти відповідь на їх питання Кращим предметним покажчиком вважається той, який відкриває читачеві найкоротший шлях від постановки ним питання до знаходження відповідного тексту в книзі Індекси бази даних відіграють таку ж роль

Незважаючи на те що індекси можуть бути складними, мета індексації проста: скорочення числа читаних фізичних сторінок

Основи індексації

Існують два основних типи індексів Предметний покажчик, який фізично сортує текстові сторінки, подібно телефонній книзі, називається кластеризувати, так як самі дані збудовані в специфічному порядку Цей тип предметного покажчика фізично знаходиться в тексті книги Природно, текст може бути відсортований в даному випадку тільки в одному порядку Аналогічно, таблиці SQL Server можуть мати тільки один фізичний порядок сортування, і саме він називається кластеризувати індексом таблиці

Некластерізованний індекс подібний предметного покажчику в кінці книги – він відправляє читача на певні сторінки Будь-яке питання може бути без праці знайдений в тексті, якщо спочатку знайти його в предметному покажчику, а потім вирушити за посиланням на конкретну сторінку SQL Server також має некластерізованний індексами, які виконують сортування, використовуючи стовпці, відмінні від кластеризованого індексу

Стовпці, які використовуються в індексах, називають ключовими

Так як первинні ключі реалізують унікальний метод ідентифікації будь-якого рядка, індекси та первинні ключі взаємоповязані – первинний ключ повинен бути індексований, але в той же час він може бути кластеризувати або некластерізованний

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

Додаткова Індекси таблиць не можна плутати з індексованими уявленнями Редак-інформація ція Enterprise Edition містить функцію денормалізації, яка будує кластерізованний індекс, що поширюється на безліч таблиць Неправильне використання індексованих уявлень може істотно знизити продуктивність операційних баз даних У главі 53 ми більш детально поговоримо про індексованих виставах

Групові індекси

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

Рис 501 Кластерізованний індекс повязує листові вузли сторінок індексів зі сторінками даних, забезпечуючи той же порядок даних, що і в індексі

Кластерізованний індекс може вплинути на продуктивність одним з описаних нижче способів

■ Коли операція пошуку знаходить рядок, використовуючи кластерізованний індекс, потрібні дані знаходяться саме в ній Це робить стовпець, використовуваний для ідентифікації рядків, можливим кандидатом для первинного ключа і ідеальним – для кластеризованого індексу

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

/ Будь таблиця має деякий фізичний порядок Якщо таблиця не має

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

Некластерізованний індекси

Некластерізованний називається індекс у вигляді збалансованого дерева, що починається з кореневого вузла та зростаючого через проміжні вузли до листовим вузлів Листові вузли вказують безпосередньо на рядки сторінок даних (див рис 501) Таблиця SQL Server 2005 може мати до 249 ^ кластеризованих індексів, але мені на практиці не зустрічалися таблиці, що вимагають більше десяти добре продуманих індексів

Некластерізованний індекс може бути створений за обчислювані стовпці Для включення можливості створення індексу або індексованого подання по обчислювані стовпці слід встановити для параметра quoted_identif ier значення on

Створення індексів

У вікні Object Explorer утиліти Management Studio існуючі індекси кожної таблиці перераховані під вузлом Databases ^ Tables ^ Indexes Властивості кожного нового або існуючого індексу можна коригувати в діалоговому вікні Index Properties (рис 502) Це вікно відкривається для існуючого індексу клацанням правої кнопки миші на його імені і вибором у контекстному меню пункту Properties Нові індекси створюються за допомогою контекстного меню вузла Indexes конкретної таблиці

У утиліті Management Studio індекси відображаються як вузли на панелі Object Explorer За допомогою вибору в контекстному меню вузла Indexes пункту New Index можна створити новий індекс У відкривається при цьому формі містяться чотири вкладки

■ General Містить імя індексу, його тип, властивість унікальності, а також ключові стовпці

■ Options Управляє режимом роботи індексу Тут же будь індекс може бути відключений і знову включений

■ Included Columns Містить неключові стовпці, службовці оболонкою індексу

■ Storage Дозволяє помістити індекс в обрану файлову групу

Puc 502 Параметри будь-якого індексу можна встановити в діалоговому вікні Index Properties утиліти Management Studio

При відкритті вікна параметрів існуючого індексу воно містить також і дві додаткові вкладки

■ Fragmentation Відображає детальну інформацію про стан індексу

■ Extended Properties Містить додаткові параметри, які визначаються користувачем

Зміни, які вносять у вікні параметрів індексу, можна застосувати негайно за допомогою клацання на кнопці Про К їх застосування можна відкласти на заданий час, а також втілити всі зміни в сценарій Для цього можна скористатися значками у верхній частині вікна

У програмному коді індекси створюються за допомогою інструкції CREATE INDEX У наступному прикладі створюється кластерізованний індекс IxOrderld, заснований на зовнішньому ключі OrderlD таблиці OrderDetail:

CREATE CLUSTERED INDEX IxOrderlD ON dboOrderDetail (OrderlD)

I Для вилучення вичерпної інформації про індекси за допомогою про-

S VS граммного коду використовують такі функції і подання каталогів:

I&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp * sysindexes, sysindex_columns, sysstats, sysstats_columns, sysdm_db_

              *    index_physical_stats, sysdm_index_operational_stats, sysindexkey_

property і sysindex_col

Кластерізованний індекс створюється автоматично при визначенні первинного ключа Для видалення індексу використовується інструкція DROP INDEX, в якій вказується імя таблиці та імя індексу, наприклад:

DROP INDEX OrderDetailIxOrderlD

Дополнітешрая Створені індекси не підтримують ефективне стан автоматично, інформація Операції оновлення можуть фрагментировать індекси і змінювати коефіцієнти- ент заповнення їх сторінок У цьому розділі ми лише згадуємо про необхідність обслуговування індексів, тогдп як у главі 37 розповідалося про вимоги, необхідних для забезпечення продуктивності індексів

Складові індекси

Складовим називають кластерізованний або некластерізованний індекс, що включає безліч стовпців На практиці більшість індексів є складовими Якщо ви використовуєте вікно параметрів індексу утиліти Management Studio, то складені індекси створюються за допомогою додавання безлічі стовпців у вкладці General Для створення складеного індексу в програмному коді він повинен бути оголошений за допомогою інструкції DDL CREATE INDEX після створення таблиці У наступному прикладі створюється складений кластерізованний індекс для таблиці GUIDE бази даних СНА2:

CREATE CLUSTERED INDEX IxGuideName ON dboGuide (LastName, FirstName)

Порядок стовпців в складеному індексі дуже важливий Щоб при пошуку отримати всі переваги складеного індексу, останній повинен містити найбільш часто використовувані стовпці в напрямку зліва направо Якщо складовою індекс виглядає як lastname, firstname, то пошук тільки по firstname не використовуватиме індекс, а пошук по lastname або спільно з lastname і firstname – буде

Додаткова SQL Server 2005 може індексувати слова в шпальтах за допомогою функції інформація повнотекстового пошуку, яку ми обговорювали в главі 13

Первинні ключі

Первинний ключ може бути спочатку визначений як кластерізованний або некластерізованний індекс Однак, щоб змінити тип індексу, обмеження первинного ключа повинно бути видалено або знову створено Це досить важке завдання, якщо присутня безліч зовнішніх ключів або якщо таблиця реплицируется

Додаткова Про створення первинних ключів см в главі 17

інформація

Покривають індекси

Покривають називають будь індекс, який повністю задовольняє потребам конкретного запиту SELECT Так як СУБД SQL Server сама вибирає, який індекс використовувати для пошуку даних, існує ймовірність, що в некластерізованний індексі запитом знадобляться всі стовпці У даному випадку реляционное ядро ​​буде витягати дані з індексних сторінок і ніколи не буде здійснювати читання зі сторінок даних Це істотно скорочує операції введення-виведення, так як читання здійснюється з більш вузьких таблиць, що містять на одній сторінці більше даних, а додаткове читання зі сторінок даних взагалі не виконується

При проектуванні покриває індексу дуже важливо усвідомлювати, як кластерізованний індекс впливає на некластерізованний Оскільки некластерізованний індекс повинен мати здатність звертатися до сторінок даних, на своїх листових вузлах він повинен містити ключовий стовпець кластеризованого індексу (якщо в таблиці такий існує) При цьому стовпці кластеризованого індексу включаються в кінець кожного некластерізованний-го індексу (навіть якщо ви їх не бачите явно в діалоговому вікні властивостей індексу) Наприклад, якщо деяка таблиця має кластерізованний індекс за стовпцем ContactID і некластерізованний по стовпцях LastName і FirstName, то некластерізованний індекс містить дані зі стовпців LastName, FirstName (відсортовані), а також ContactID (несортовані) Знання цього факту дуже важливо при проектуванні покривають індексів

Покриває індекс може мати необхідність включати деякі стовпці, які не вимагають реляционное ядро ​​для ідентифікації рядків, відсіяних пропозицією WHERE Ці додаткові, неключові стовпці не відчувають потребу в сортуванні в збалансованому дереві індексу – вони включаються виключно з метою повернення стовпців запитом SELECT

Недоліком покривають індексів в попередніх версіях SQL Server було Новинка 4 те, що при оновленнях повинні були сортуватися всі стовпці – навіть ті, 2005 які не використовувалися при відборі рядків, а були включені виключно

для повернення даних Здатність версії SQL Server 2005 відокремлювати неключові стовпці підвищила продуктивність операцій оновлення з використанням покривають індексів, в яких не сортуються неключові стовпці При цьому за рахунок зменшення розміру збалансованого дерева індексу покращилася продуктивність вилучення даних запитом

Для визначення неключових стовпців в некластерізованних індексах використовується параметр INCLUDE Ці неключові стовпці не сортуються як частина структури збалансованого дерева індексу і включаються тільки в його листові вузли У наступному прикладі створюється індекс, сортують дані по стовпцю OrderNumber і включає дані з шпальти OrderDate:

CREATE NONCLUSTERED INDEX IxOrderNumber ON dbo[Order] (OrderNumber)

INCLUDE (OrderDate)

Завдяки включаються стовпцях як вузької копії широкої таблиці, які SQL Server постійно синхронізує з вихідною таблицею, для вилучення даних не потрібно читання додаткових сторінок

Включаються стовпці не враховано в обмеженнях некластерізованний індексу-16 ключових стовпців і 900 байтів Насправді в покриває індекс можна включити до 1023 неключових стовпців В якості включаються можуть бути також і стовпці з особливо великими типами даних – XML, varchar (max), nvarchar (max) і varbinary (max), – навіть незважаючи на те, що вони не можуть виступати в ролі ключових стовпців

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

Місцезнаходження файлової групи

Якщо база даних використовує безліч іменованих файлових груп, то індекс може бути створений в певній з них Для цього у визначенні індексу використовується параметр

ON імя_файловой_группьг

CREATE NONCLUSTERED INDEX імя_індексу ON Table (стовпці)

ON імя_файловой_группи

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

Додаткова Фізичне розміщення таблиць і індексів може бути налаштоване і інформація більш глибоко, з використанням файлових груп і розділів Більш докладно _ ці теми ми обговоримо в главі 53

Параметри індексів

Індекси SQL Server 2005 мають кілька параметрів, в тому числі унікальність, виділення простору, а також параметри продуктивності

Унікальні індекси

Параметр UNIQUE INDEX є дечим більшим, ніж просто індексом з обмеженням на унікальність, – унікальним індексам доступна оптимізація Первинний ключ або обмеження на унікальність автоматично створюють унікальний індекс

У Management Studio унікальний індекс створюється за допомогою установки прапорця Unique у вкладці General діалогового вікна параметрів індексу

У програмному коді унікальність індексу вказується за допомогою додавання у визначення ключового слова UNIQUE:

CREATE UNIQUE INDEX OrderNumber ON [Order] (OrderNumber)

Коефіцієнт заповнення індексу

Будь-якому індексом потрібно трохи вільного простору в дереві, щоб вставка нових записів не призводила до реструктуризації індексу Коли серверу потрібно вставити новий запис в заповнену сторінку, він розбиває цю сторінку на дві, після чого записує дві наполовину повні сторінки на диск Такий хід речей викликає три потенційні проблеми: розбивається сама сторінка, нові сторінки більше не є послідовними, і на кожній сторінці міститься менший обсяг інформації У результаті для читання того ж обсягу даних буде потрібно переглянути більшу кількість сторінок

Оскільки індекс являє собою збалансоване дерево, кожна сторінка повинна містити як мінімум два рядки Коефіцієнт заповнення та параметр pad index впливають як на проміжні сторінки, так і на листові вузли, як показано в табл 501

Таблиця 501 Коефіцієнт заповнення та параметр pad index

Коефіцієнт

заповнення

Проміжні сторінки

Листовий вузол

0

Одна вільна запис

100%-ве заповнення

1-99

Одна вільна запис або обсяг, менший коефіцієнта заповнення, якщо встановлено параметр pad index

Обєм, менший коефіцієнта заповнення

100

Одна вільна запис

100%-ве заповнення

Коефіцієнт заповнення застосовується тільки до листовим вузлам індексу, якщо до нього не застосовано параметр pad index Цей параметр вказує серверу застосовувати слабкість коефіцієнта заповнення також і до проміжних рівням збалансованого дерева

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

Додаткова Коефіцієнт заповнення індексу у міру поділу сторінок поступово ут-ікформація рачівает свою роль Для відновлення коефіцієнта заповнення план обслуговування повинен включати в себе періодичну реіндексацію Інформація про порядок підтримки індексів міститься в главі 37

У Management Studio коефіцієнт заповнення встановлюється у вкладці Options діалогового вікна параметрів індексу У програмному коді Т-SQL параметри коефіцієнта заповнення та index pad вказуються після команди CREATE INDEX У наступному прикладі створюється індекс OrderNumber з 15% вільного простору як на листових вузлах, так і на проміжних сторінках:

CREATE NONCLUSTERED INDEX IxOrderNumber ON dbo[Order] (OrderNumber)

WITH FILLFACTOR = 85, PAD_INDEX = ON

Управління блокуванням індексів, їх створення в реальному часі і ограни-Норінко чення паралелізму індексів є новими параметрами, що зявилися

2005 в версій SQL Server 2005 Для параметрів pad_index, fillfactor, sort_in_db,

ignore_dup_key, statistiсs_norecompute і drop_existing був змінений синтаксис Новий синтаксис вимагає обовязкового включення вираження = оп З міркувань зворотної сумісності продовжує підтримуватися і старий синтаксис, проте в майбутніх версіях цього вже не буде

Обмеження блокувань і паралелізму

Режим роботи блокувань у запитах, що використовують індекси, може управлятися за допомогою параметрів allow_row_locks і allow_page_locks Зазвичай ці блокування дозволені

Порядок сортування індексів

СУБД SQL Server здатна створювати спадні індекси Будь-який запит, що використовує пропозицію ORDER BY, призведе до сортування по зростанню, якщо в цьому пропозиції не буде явно вказано ключове слово DESC

В інструкції DDL CREATE INDEX ключові слова AS С і DESC йдуть безпосередньо за імям стовпця

Параметр ігнорування дубльованих ключів

Параметр I GNORE_DUP_KEY не робить впливу на сам індекс, а тільки на те, як згодом індекс буде впливати на зміни даних

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

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

У наступному прикладі повторюється попередня інструкція створення унікального індексу, але в ній використаний параметр ігнорування дубльованих ключів:

CREATE UNIQUE INDEX OrderNumber ON [Order] (OrderNumber)

WITH IGNORE_DUP_KEY = ON

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

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

Параметр заборони перерахунку статистики індексу

Оптимізатор запитів SQL Server залежить від статистики розподілу даних в питанні визначення, який з індексів є більш істотним у конкретному критерії пошуку в таблиці Зазвичай SQL Server оновлює цю статистику автоматично Водночас безпосередньо перед запитом деякі таблиці можуть отримати великий обсяг даних, і в цьому випадку статистика може виявитися застарілою Спеціально для ситуацій, в яких статистика вимагає оновлення вручну, призначений параметр statistics_norecompute, що скасовує автоматичне оновлення статистики Практично для всіх індексів цей режим роботи не рекомендується

Сортування в базі tempdb

Параметр sort_in_tempdb = on змінює метод створення індексу, форсуючи використання бази tempdb, а не памяті Якщо індекс постійно віддаляється і відтворюється, то цей параметр здатний скоротити час створення індексу У більшості індексів цей параметр не має великого значення, до того ж він не обовязковий

Відключення індексу

Будь індекс може бути тимчасово відключений Для цього досить зняти прапорець Use Index у вкладці Option діалогового вікна параметрів індексу У програмному коді T-SQL цей ефект досягається за допомогою включення параметра DISABLE в інструкцію DDL ALTER INDEX:

ALTER INDEX [IxContact] ON [dbo][Contact] DISABLE

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

Відключення кластеризованого індексу фактично призводить до відключення Увага всієї таблиці

Щоб знову включити індекс, використовується команда ALTER INDEX REBUILD WITH:

ALTER INDEX [PK____ Contact      0BC6C43E]

ON [dbo][Contact]

REBUILD WITH ( PAD_INDEX = OFF,

STATISTICS_NORECOMPUTE = OFF,

ALLOW ROW LOCKS = ON,

ALLOW_PAGE_LOCKS = ON,

SORT_IN_TEMPDB = OFF,

ONLINE = OFF )

Створення базових індексів

Навіть перед налаштуванням місцезнаходження кількох індексів легко визначити Ці базові індекси є першим кроком у створенні цілісного набору індексів Нижче наведено кілька рекомендацій, якими варто скористатися перед створенням цих базових індексів

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

2 Створіть некластерізованний індекси для стовпців кожного зовнішнього ключа, за винятком тих, які були проіндексовані в п 1 Як ключі індексу використовуйте тільки значення зовнішнього ключа

3 Створіть одностолбцовий індекс для всіх стовпців, які найбільш ймовірно будуть зявлятися в пропозиціях WHERE, ORDER BY або GROUP BY

У той час як запропонований план індексації далекий від досконалості, він пропонує початковий компроміс між відсутністю індексів і налаштованими індексами В принципі його можна розглядати як базовий рівень продуктивності стосовно подальшої налаштуванні індексів

Джерело: Нільсен, Пол 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>

*

*