Когато искате максималната скорост на извличане и имате и двете колони в условията за свързване или където, НО понякога колона a има по-висока селективност, а понякога колона b има по-висока селективност и искате да се възползвате от този факт от единичен индекс.
Също така мисля, че вашето съотношение размер на данни / производителност на машината трябва да е доста високо и в същото време ще трябва (предполагайки) да сте готови да наречете всяко подобрение необходимост (дори и само с няколко процента).
Все пак опитът учи, че нещата зависят от много фактори; със специфични RDBMS и среди на приложения, по-добре е да изпълнявате свои собствени бенчмаркове.
РЕДАКТИРАНЕ:Допълнително обяснение относно съставните индекси.от wikipedia
:
"Редът, в който колоните са изброени в дефиницията на индекса, е важен. Възможно е да се извлече набор от идентификатори на редове, използвайки само първата индексирана колона. Това обаче не е възможно или ефективно (на повечето бази данни), за да извлечете набора от идентификатори на редове, използвайки само втората или по-голяма индексирана колона.
Например, представете си телефонен указател, който е организиран първо по град, след това по фамилия и след това по собствено име. Ако ако им е даден град, можете лесно да извлечете списъка с всички телефонни номера за този град. Въпреки това, в този телефонен указател би било много досадно да намерите всички телефонни номера за дадено фамилно име. Ще трябва да търсите във всеки град раздел за вписванията с това фамилно име."
Обясненията на Уикипедия може би са твърде опростени, но ви дава основната идея (като аналогиите вървят, имайте предвид, че телефонните указатели обикновено имат групирани индекси и това не би било вашият общ индекс на базата данни).
В зависимост от размера на индекса спрямо размера на структурата от данни спрямо наличната памет срещу селективността на първата колона на индекса все пак може да е много по-евтино да се използва грешно подреден индекс, отколкото да се използва сканиране на таблици.
А, просто се сетих за по-добра аналогия с пример, който търсите. Представете си хубав учебник, той ще има съдържание с глави и подглави и номер на страниците, на които се намират (което е неклъстериран индекс, който съдържа указатели към записи на данни - страници). Сега си представете, че учебникът е по стандарта SQL-92, тогава повечето термини в TOC ще бъдат SQL термини (придържайте се към това предположение). Вие също ще имате друг индекс в края на книгата, който ще избройте всички интересни термини в азбучен ред (да предположим с имената на основните глави) и номера на страници.
За въпроси като „Кажи ми всички глави, под които се появява DISTINCT“, ще използвате втория индекс. (тъй като селективността на следващото поле е висока)
За въпроси като „Кажете ми броя на термините, които се появяват в първата глава“, бихте използвали TOC
Така че за въпроси като "SELECT описано ли е в DML глава?" може да използвате някой от индексите. (тъй като селективността и на двете полета е висока) Но ако TOC на самия DML е дълъг 3 страници и записът SELECT в индекса има само петнадесет реда, вероятно ще отидете на второто, а това е пример за това, когато се възползвате от двата индекса.
Сега, ако смятате, че това е твърде далеч, вземете под внимание база данни от сканираната библиотека на Конгреса. :)
Както казах преди, цялото планиране е наред, но в крайна сметка изпълнете свои собствени показатели.
