Я докато чакам...

да взема да запитам:
Нормално ли е MySQL да индексира ~90000 записа по DateTime за повече от десет (към часа на поста) минути?
За фултекст съм склонен да го приема за нормално, но за datetime...
Просто не ми се ще да го спирам по средата, ако случайно не е забил :-)
p.s. V4.0.1

Индексирането мина, но не реши проблема.
Цялата работа e заради тази заявка:

SELECT Title FROM Articles
WHERE FolderId = <SomeId>
AND Edited = <SomeDate>
AND MATCH(Title, UpperHead, SubHead, Body, Author) AGAINST('SomeWords' IN BOOLEAN MODE)

Изпълнява се за едно и също (дъъъългичко) време в горния и в този вид:

SELECT Title FROM Articles
WHERE MATCH(Title, UpperHead, SubHead, Body, Author) AGAINST('SomeWords' IN BOOLEAN MODE)
AND FolderId = <SomeId>
AND Edited = <SomeDate>

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

Някои подробности и наблюдения:
1. Има индекси по всички полета в WHERE-клаузата;
2. Има не повече от 200 записа с едно и също FolderId;
3. Заявките само с WHERE FolderId=<SomeId> се изпълняват светкавично (а вече и тези с Edited, вследствие на индексирането от първия пост :-\ );
4. Полето Body съдържа доста текст и фултекст-търсенето е времеемко;
5. Именно като следствие от 3 и 4 слагам първо "филтъра" по FolderId и после по FullText.
6. ... но ефект няма.

Отивам пак да чета и пробвам, пък ако някой даде и hint ... :-)

p.s.: След кратък размисъл ми хрумна, че може би причнината е в начина на работа на fulltext-индекса. Ако не се лъжа, той съдържа съответствие "Дума"->"Записи", като подреждането е по "Дума", и в такъв случай няма как предварително да се определят (ограничат) записите, в които да се търси. ДАНО ДА НЕ СЪМ ПРАВ!
Но май съм близо, защото като сменя MATCH-AGAINST с LIKE (което рови само в текущия запис), заявката лети. Само че така не ми върши работа :-((

1. Първо и най-важно.

4.0.12 е налице без да е алфа, бета, гама. 4.0.13 трябва да излезе тази седмица.

2. А ти за EXPLAIN не си ли чувал?

3. За Full-text. Естествено, че си прав. Ако имаш идея как да се направи по-добре - кажи.

4. "Има индекси по всички полета в WHERE-клаузата"
Което, ще рече че индексите не са ти добре оптимизирани ако имаш предвид отделен индекс за всяка колона.

MySQL може да използва Един И Само Един Индекс на таблица в дадена заявка.

Което пък ще рече, че за твоята заявка един доста добър индекс (вероятно) би бил
(FolderId, Edited) - защото той ще работи за
FolderId = <> AND Edited = <>
Докато от два отделни MySQL ще избере само единия.


5. "слагам първо "филтъра" по ..." Къде това? Никъде нищо не слагаш. Четиво за заспиване: USE INDEX, FORCE INDEX, IGNORE INDEX

6. Ами отговора на първия постинг ти го даде във втория. Индексите са ти много т.е. доста големички. Вероятно .MYI файла ти е около три пъти по-голям от .MYD

PS Много EXPLAIN ....

salle.online.bg/sig

Иии, гледай какви работи може да се случат от неточен изказ и заплесия :-\\
Айде пак по точки:
1. Както се вижда от коментарите (и моите, и твоите), проблемът е принципен и не опира толкова до версията (fulltext-търсенето си е пъргаво само по себе си, намесих го за да се опитам да обясня проблема);
2. EXPLAIN ми каза същото, което установих и емпирично след първите няколко теста :-));
4. Индексът е точно (FolderId, Edited);
5. И тука стигаме до основното объркване: Някак си се подлъгах да разсъждавам по логиката на повечето компилатори при смятане на израз от типа "Cond1 AND Cond2 AND ... AND CondN". Тук изчисленията тръгват отляво и продължават надясно само ако има смисъл (т.е., всички изчислени до момента условия са TRUE). В контекста на DB-то, това разсъждение изглежда така:
"Взимаш всички записи с необходимото FolderId (филтър 1) и после претърсваш само тях за ключовите думи". Очевидно неприложимо с fulltext-индекс (както и загрях в предния си пост).

btw, Articles.MYD=350MB, Articles.MYI=202MB. Не съм се замислял да анализирам големините, а може би трябва.

хмм....

Значи не си мниги прав за компилаторите защото един добре опитимизилащ компилатор може да се усети, че примерно 3-тото условие в един AND е винаги вярно и да промени реда на изчисление.

При SQL сървърите пък иде реч за Оптимизатор а на него това му е работата - да измисли най-добрия план.
В твоя случая ако имаше два индекса по FolderId и Edited оптимизатора на базата на статистиката за индексите ще предпочете единия или другия - този който ограничава повече броя на редовете.

Т.е. ако оптимизатора очаква, че
FolderId = <> ще върне 20000 реда
а
Edited = <> само 150 то тогава тава е по-добрият кандидат за индекс и съответно и това условие в AND е по-добре да се приложи първо.

Следващият момент е, че индексите при MyISAM преди 4.1 са само B-tree поради което те работят най-добре по Префикс.

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

Абе то това си едно тресавище от теория, практика, проби и грешки ...

salle.online.bg/sig

Мисля, че стана ясно :-\
Само да уточня, че в повечето случаи (коментираната заявка е изключение) датата не ме вълнува и ползвам индекс само по FolderId, та затва съм сложил реда така (FolderId, Edited)