Oracle:има ли значение редът на колоните в индекс?

1. Ако a и b и двете имат 1000 различни стойности и те винаги се запитват заедно, тогава редът на колоните в индекса всъщност няма значение. Но ако a има само 10 различни стойности или имате заявки, които използват само една от колоните, тогава има значение; в тези сценарии индексът може да не се използва, ако подреждането на колоните не отговаря на заявката.
2. Колоната с най-малко различни стойности трябва да е първа, а колоната с най-отличителните стойности последна. Това не само увеличава максимално полезността на индекса, но също така увеличава потенциалните печалби от компресирането на индекса.
3. Типът на данните и дължината на колоната оказват влияние върху възвръщаемостта, която можем да получим от компресирането на индекса, но не и върху най-добрия ред на колоните в индекс.
4. Подредете колоните с най-малко селективната колона първо и най-селективната колона последна. В случай на равенство с колоната, която е по-вероятно да се използва самостоятелно.

Единственото потенциално изключение за 2. и 3. е с колони DATE. Тъй като колоните на Oracle DATE включват елемент от време, те може да имат 86400 различни стойности на ден . Въпреки това повечето заявки в колона с данни обикновено се интересуват само от елемента ден, така че може да искате да вземете предвид само броя на отделните дни във вашите изчисления. Въпреки че подозирам, че това няма да повлияе на относителната селективност само в няколко случая.

редактиране (в отговор на коментар на Ник Пиърпойнт)

Двете основни причини за водеща с най-малко селективна колона са

1. Компресия на индекса
2. Пропускане на четения на индекс

И двете правят своята магия, тъй като знаят, че стойността в текущия слот е същата като стойността в предишния слот. Следователно можем да увеличим възвръщаемостта от тези техники, като минимизираме броя на промените на стойността. В следващия пример A има четири различни стойности и B има шест. Те представляват компресируема стойност или индексен блок с възможност за пропускане.

Least selective column leads ...

A          B
---------  -
AARDVARK   1
"          2
"          3
"          4
"          5
"          6
DIFFVAL    1
"          2
"          3
"          4
"          5
"          6
OTHERVAL   1
"          2
"          3
"          4
"          5
"          6
WHATEVER   1
"          2
"          3
"          4
"          5
"          6

Най-селективните водещи колони ...

B  A
-  --------
1  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
2  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
3  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
4  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
5  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER
6  AARDVARK
"  DIFFVAL
"  OTHERVAL
"  WHATEVER

Дори в този тривален пример (A, B) има 20 слота с възможност за пропускане в сравнение с 18 от (B, A) . По-голямо несъответствие би генерирало по-голяма възвръщаемост на инвестициите при компресиране на индекса или по-добра полезност от четенията на Index Skip.

Както е в случая с повечето евристики за настройка, ние трябва да сравним с помощта на действителни стойности и реалистични обеми. Това определено е сценарий, при който изкривяването на данните може да има драматично въздействие върху ефективността на различните подходи.

„Мисля, че ако имате силно селективен първи индекс, тогава – от гледна точка на производителността – ще направите добре да го поставите на първо място.”

Ако имаме силно селективна колона, тогава трябва да й изградим собствен индекс. Допълнителните ползи от избягването на операция FILTER върху шепа редове е малко вероятно да бъдат превъзмогнати от режийните разходи за поддържане на съставен индекс.

Индексите с няколко колони са най-полезни, когато имаме:

• две или повече колони със средна селективност,
• които често се използват в една и съща заявка.