Обща информация
Какво е единен индекс и какво е съставен индекс? Кога да създам нов композитен индекс и на какво трябва да обърна внимание в него? Тази статия е основно обобщение на някои дискусии в интернет.
Едно. Концепция
Единичен индекс е ситуация, при която индексът е изброен в една колона, т.е. твърдението за създаване на нов индекс се реализира само върху една колона.
Потребителите могат да създават индекси в няколко колони, които се наричат композитни индекси (комбинирани индекси). Съставните индекси се създават по абсолютно същия начин като единичните индекси. Но композитните индекси изискват по-малко натоварване при операции с база данни и могат да заменят множество отделни индекси. Когато броят на редовете в таблицата е много по-голям от броя на ключовете, този метод може значително да ускори скоростта на заявки в таблицата.
Съществуват две понятия едновременно – тесни индекси и широки индекси, тесни индекси се отнасят до индекси с 1-2 колони и обикновено се отнасят до един индекс, освен ако не е посочено друго. Широк индекс е индекс с повече от 2 колони.
Важен принцип на дизайна на индекси е използването на тесни индекси вместо широки, тъй като тесните индекси обикновено са по-ефективни от комбинираните. По-тесните индекси дават на оптимизатора повече избор, което често помага за подобряване на представянето.
Две. Употреба
Създай индекс
Създаване на индекс IDX1 върху таблица 1(COL1,COL2,COL3)
Запитване
изберете * от таблица1, където col1= A и col2= B и col3 = C
В този момент оптимизаторът на заявки не сканира таблицата, а директно взема данните от индекса, защото в индекса има данни, които се наричат overlay заявка, а скоростта на заявката е много висока.
Три. Бележки:
1. Кога да се използва сложен индекс
При условие where полето се индексира, а ако се използват няколко полета, се използва композитен индекс. Обикновено не изграждайте индекси в полето select (ако искате да направите заявка select col1, col2, col3 от mytable, не ви трябва горният индекс). Индексирането въз основа на условията е изключително важен принцип. Внимавайте да не използвате твърде много индекси, иначе това ще има голямо влияние върху ефективността на обновяването на таблиците, защото трябва да отделите много време за създаване на индекси при работа с таблици.
2. За композитни индекси, при използване на заявка, най-добре е да се следва редът на намиране на индекси, който е най-ефективен. Например:
IDX1:Create index idx1 върху таблица 1(col2,col3,col5)
изберете * от таблица1, където col2=A и col3=B и col5=D
Ако е "select * от таблица 1, където col3=B и col2=A и col5=D"
Или "select * from table1, където col3=B" няма да използва индекса, или ефектът не се забелязва
3. Ще замени ли композитният индекс един индекс?
Много хора смятат, че добавянето на което и да е поле към клъстерирания индекс може да подобри скоростта на заявките, но някои са объркани: Ако полетата със сложни клъстери се заявяват отделно, ще се забави ли скоростта на заявките? С този въпрос нека разгледаме следната скорост на заявка (наборът от резултати е 250 000 данни) :( колона за дата fariqi е на първо място в началната колона на композитния агрегационен индекс, а потребителското име neibuyonghu е второ)
IDX1:create index idx1 on Tgongwen(fariqi,neibuyonghu)
(1) изберете гид, фарики, нейбуюнгху, титла от Тгонгвен
Къде Фарики>'2004-5-5'
Скорост на заявка: 2513 ms
(2) изберете гид, фарики, нейбуюнгху, титла от Тгонгвен
където fariqi>'2004-5-5' и neibuyonghu='офис'
Скорост на заявка: 2516 ms
(3) изберете гид, фарики, нейбуйонгху, титла от Тгонгвен
където neibuyonghu='офис'
Скорост на заявка: 60280 милисекунди
От горните експерименти виждаме, че ако само началната колона на клъстерирания индекс се използва като условие за заявка, скоростта на заявки на всички колони с композитен клъстериран индекс е почти еднаква, дори малко по-бърза, отколкото при използване на всички композитни колони на индекса (когато броят на наборите от резултати от заявки е същият). Ако само неначалните колони на комплексния агрегиран индекс се използват като условия за заявка, този индекс няма да направи нищо. Разбира се, скоростта на заявки на изявления 1 и 2 е съща, защото броят на записите в заявката е еднакъв; ако се използват всички колони на композитния индекс, а резултатите от заявката са малко, това ще формира "презаписване на индекса", така че производителността да бъде оптимизирана. Също така, имайте предвид, че независимо дали често използвате други колони в агрегатния индекс, водещата колона трябва да е тази, която се използва най-често.
[Източник: Схема за оптимизация на заявки и алгоритъм за пагиниране http://blog.csdn.net/chiefsailor/archive/2007/05/28/1628339.aspx]
4. Трябва ли да създам един индекс и композитен индекс в една и съща колона по едно и също време?
Експеримент: Sysbase 5.0 таблица таблица 1 полета: col1, col2, col3
Стъпки за теста:
(1) Създаване на индекс idx1 върху col1
Изпълни select * от таблица1, където col1=A използва idx1
Execute select * от таблица 1, където col1=A и col2=B също използват idx1
(2) Изтрийте индекса idx1 и след това създайте idx2 върху (col1,col2) композитен индекс
И двете заявки използват idx2
(3) Ако и двата индекса idx1 и idx2 съществуват
Не е там, където col1='A' използва idx1; където col1=A и col2=B използват idx2.
Оптимизаторът на заявки използва един от преди това често използваните индекси. Използвайте idx1 или idx2.
Може да се види, че
(1) За таблица, ако има сложен индекс върху (col1, col2), няма нужда да се създава един индекс върху col1 едновременно.
(2) Ако условията за заявка го изискват, можете да добавите индекса на състава върху (col1, col2), когато вече има един индекс върху col1, което може да подобри ефективността до известна степен.
(3) Няма особено много ползи от създаването на композитен индекс с множество полета (съдържащи 5 или 6 полета) едновременно; относително погледнато, установяването на индекс с множество тесни полета (съдържащи само едно или най-много 2 полета) може да постигне по-добра ефективност и гъвкавост.
5. Трябва ли да покрия заявката?
Обикновено е най-добре да не се използва стратегия, която акцентира върху пълното покритие на запитванията. Ако всички колони в клаузата Select са презаписани с неклъстериран индекс, оптимизаторът ще разпознае това и ще осигури добра производителност. Въпреки това, това често води до прекалено широк индекс и прекомерна зависимост от вероятността оптимизаторът да използва политиката. Обикновено тесните индекси се използват за по-голям брой заявки, което осигурява по-добра производителност при големи заявки. |
Публикувано в 29.01.2015 г. 13:06:03 ч.
|
|
|
