Индекси

Здр:-)
Чудех се има ли някакви по-специфични правила или препоръки когато в една таблица се задава кои колони трябва да са key или index. Защото е много лесно да направиш всичко което имаш индекс, но дали това е правилно?

Хм, отдавна не бях поствал тука, най-после нещо достатъчно просто, за да се включа . Начи сега, хич не е най-лесно да се наблъскат индекси навсякъде, защото:
1. При всяка операция ти се добавя, чете или ъпдейтва освен данните и индекса, свързан с тях. Това губи време.
2. Индексите заемат място. Особено в по-малки таблици понякога заемат относително много място. В моя форум доскоро индексния файл беше по-голям от файла с данните.
Та затва индекс се слага по полетата, по които се очаква да се търси. По-задълбочено обяснение на последното понятие, вервам, ще ти дадат другите от клуба .

It`s more fun to compute

[линк]

няма смисъл да се индексират полета от типа "пол" да кажем, където има две стойности...и дори и три да са пак няма смисъл....

няма смисъл, да се индексира поле от тип текст, ако ще се търсят части от полето...демек ако ще търсиш ключови думи и те са подредени в едно поле и разделени със запетайки да кажем...индекса с нищо няма да ти облекчи живота...

мда, имам пропуск. Нямах предвид индекси абсолютно навсякъде, а само там където ще се търси. Явно е нужно, и отговорът на въпроса ми е: да, там където ще се търси слагай индекси, така ли?:-))

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

аз имам як сървър, много място и малко натоварване - никакво значение няма колко съм индексирал и къде.....

Като за начало индексирай само полетата които са в WHERE клаузата и то ако за цифрови.
После можеш да си вземеш книгата на Пол ДюБоа "MySQL" и да прочетеш от там "Оптимизация на заявките". За индексите пише и в официалната документация. Има едно "How mysql optimizes....." - много полезна информация можеш да получиш от там.
Виж другите какво са писали по-въпроса. Мога да допълня, че "не е хубваво" да индексираш стрингове които са дълги...

Можеш и опитно(по емпиричен път - както казваше един доцент) да видиш как се променя производителността в зависимост от идексирането на някое поле.

__________________________________
Пътят към ада е осеян с добри намерения

...като си има много добро другарче.

В MySQL това е EXPLAIN

EXPLAIN SELECT .... и разказва подробно дали и какви индекси ще се използват.

salle.online.bg/sig

Има мнооооого писания по въпроса кое има смисъл да се индексира и кое не и кога.

Всичко обаче се свежда до това, че оптимизираш конкретна заявка. И въпросът, който трябва да си задаваш - ТАЗИ заявка може ли да използва Индекс и какъв?

Гадно примерче:

1. SELECT .... WHERE col_a + 1 > 2;

2. SELECT ... WHERE col_a > 2 - 1;

Виждаш ли разликата?

...
2. може да използва индекс пък 1. НЕ може.

Тъй, че мисли. Много.

Наздраве

salle.online.bg/sig

Ами... В Oracle има нещо, наречено function-based index, чрез което и заявка 1 може да ползва индекс.
Като цяло не зная как различните RDBMS организират и използват индексите, но съм съгласен с теб, че индекси се правят за оптимизиране на конкретна заявка - най-добре е да се прегледат най-често използваните заявки и да се направят походящите за тях индекси...

Nihil tam munitum quod non expugnari pecuna possit

за дългите стрингове си има решение - индексираш само първите n символа от стринга

> няма смисъл да се индексират полета от типа "пол" да кажем, където има две стойности...и дори и три да са пак няма смисъл....

ne e viarno. tova e idealen primer za clustered index.

bi li obqsnil malko po-podrobno s kakvo bi mogyl da mi e polezen takyv clusteren indeks

i kakwo mu e indealnoto za clustered index?!
ako imash 200 000 zapisa kakwa ste ti e polzata ot razdelianeto im na 2 s tozi index??

i posle kato si naprawish 5 non-clustered bazirani na tozi kakwo mislish che ste se poluchi?

Какво общо има пък клъстерен индекс?

Тая тая работа е много обширна част от теорията и практиката, но това което Торбалан спомена се свежда до правилото:

Има добри кандидати за индексирани и лоши.

Категорията зависи обаче от много фактори.
Примерът с полето Пол е учебникарски и е за да покаже, че в случай на 2 възможни стойности с равномерно разпределение 1:1 Индексът не носи особени предимства защото винаги ще се "вадят" около 50% от редовете в таблицата.

В зависимост от автора, сървъра, настройки и така нататък се споменава е граница от 10-30% от броя на редовете.

Ако дадена ЗАЯВКА ще извади по-малко от N-те % редове - има смисъл от индекс - ако са повече няма - претърсването на цялята таблица + печалбата от по-бързите INSERT,UPDATE,DELETE дават по-голяма ефективност БЕЗ индекс.

Разбира се нещата са много относителни и не случайно акцентът е върху ЗАЯВКАТА.

Простичък пример:

Таблица със 100 000 реда в която има 10 реда със N=0

Въпрос: N добър канидат за Индекс ли е?
Отговор - зависи от заявките.

SELECT ..... WHERE N = 0; Очевидно печели страхотно от използването на индек (ще бъдат проверени 10 от 100 000 т.е. 10000 пъти по-малко редове отколкото без индекс)

Ако обаче най-често използваната заявка е:

SELECT ... WHERE N > 0;

Тогава ще бъдат проверени 99 990 реда - почти никаква разлика от 100 000 -> т.е. индексът в случая с нищо не помага. И като се добавят другите фактори такъв индекс по-скоро пречи.

salle.online.bg/sig

vsichko zapochva ot zaiavkata ! dali e nujen index ili ne e izchisliavane na faktori kato golemina na bloka, dyljina an indrxiranoto pole, RAID factor, etc - ciala nauka... clustered index e vzamojen i na pole v koeto moje da ima povtariashti se stoinoisti (v dadenia primer, tablica 'Pol' sas vazmojni stoinosti 'Male, Female, Alien'); e ako predvaritelno si precenil che zaiavki ot vida '...WHERE pol = Male;' shte sa chesti - da tova e dobyr kandidat za clustered index. v tozi sluchai bazata niama da izvyrji search na 100 000 reda a prosto shte 'dovleche' zapisite koito otgovariat na kriteria (sreshu vsiaka stoinost v index-a otgovaria physicheski address kydeto se namira ostanalata chast na zapisa);