имам една таблица и две полета, по които често ще се рови...

pi_id и member_id

по тях двете има индекс, дори комбинацията от двете е primary key

има ли смисъл да правя индекси по отделно за всяко едно, ако често ще има търсения от типа WHERE pic_id=PID или пък WHERE member_id=MID

не че е критично за моите няма и хиляда записа...ама е така - да си знам..))

Съдържаниет е скрито
Влезте за да го видите

А също и

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

имам идея какво ще покаже EXPLAIN, въпроса беше по скоро принципен...

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

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

Съдържаниет е скрито
Влезте за да го видите

"като се понатрупат данни"

Ами то това е съществена част от принципа

С EXPLAIN обаче исках да ти подскажа друго - Индексираш за да ускориш Конкретна заявка при Конкретни данни.

Защото въпросът ти е малко като:
"Какви обективи да използвам?"

Я си представи, че се вясна във Фотография и задам този въпрос?

Съдържаниет е скрито
Влезте за да го видите

ще получиш няколко типа отговори
1. НИКОН (канон, пентакс, минолта...) останалите са боклук....
2. квито и да са - скъпи
3. квито и да са - евтини
4. абе обектива няма значение....важен е фотографа
5. я зарежи тия обективи, купи си една цифрова сапунерка...

в моя случай от сега е ясно, че ще имам най много заявки с филтриране по двете полета, ясно е също така, че ще има заявки с филтриране по кое да е от двете

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

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

Съдържаниет е скрито
Влезте за да го видите

Темата за Индексите е толкова обширна, че сума ти книги и статии са изписани по върпоса.

Между другото по въпроса за Full-text тези дни излезе едно много интересно нещо на Jeremy Zawodny. Ако още не си го чувал той е MySQL експерт в Yahoo!

Приеми го и като Независим Експерт какъвто всъщност е.

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

въпроса пада малко общ, но:

индекс в/у (piс_id, member_id) ще се ползва от заявки, които имат
WHERE pic_id=PID , но не и от заявки които имат WHERE member_id=MID. По принцип, ако в WHERE клаузата не фигурира водещата колона на индекса, той няма да се използва. Причината е че листата на индекса са сортирани по ключа (напр. piс_id, member_id) и ако записите дето имат определена стойност за втората (третата..) колона не са събрани на едно място в индекса.

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

Индексите разбира се забавят инсертите, което при много активни таблици се вижда с просто око (не вярвам твоя случай да е такъв).

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

За хиляда записа може да се окаже че табле скан е по-бързо: например ако да речем хиляда записа се събират на три страници и да речем записите които търсиш са на две от тях с индекс трябва да се прочете индексната страница + две стр. с данни -- пак три. Оптимизаторите осъзнават такива ситуации и праскат направо табле скан.

Друга често срещана грешка е водещата колона да е аргумент на функция -- индекса няма да се използва. Например тука някакъв гявол е кодирал в хиляди процедури нещо от типа на
WHERE pic_id=isnull(PID, pic_id)

демек, ако параметъра ПИД е зададен, избирай по него, ако не -- здраве. Това опростява кода, обаче обезсмисля индекса в/у пис-ид.

За да анализирам как се използват индексите, вземам логовете от да речем една седмица, извличам заявките от тях и ги изпълнявам на друг сървер така че да ми се генерира планът за изпълнение на куерито. Плановете ги парсвам и за всяка таблица на всяка заявка си запомням таблицата, индекса който се е ползвал (или табле скан) и какви буфери са се използвали. Това си го зареждам в една таблица и мога да я питам аджеба покажи ми случате на табле скан или покажи ми индексите дето не са се използвали никога -- може би трябва да ги махна.

ами доколкото комбинацията от двете (те всъщност станаха три) полета е РК не мога да не направя индекс...

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

то ако не си разглеждал сайта - мини и виж

Съдържаниет е скрито
Влезте за да го видите

Съдържаниет е скрито
Влезте за да го видите

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

Съдържаниет е скрито
Влезте за да го видите