В обычной ситуации (при простых текстах) время самого запроса от длинны слова если и меняется, то на доли процента. У меня из 80 миллионов ищет меньше чем за доли секунды при минимальной длинне слова в 1 симовл.

Тут дргая проблема вырисовывается. Ты помнишь что если СЛОВО есть больше чем в 50% записей то оно является спамом? Твоя система запросто выкинет в мусорник такие слова как "П", "00", "01" и подобные, так как скорей всего они у тебя повторяются часто.

Вторая проблема: из-за частого повторения fulltext с трудом будет скать фразу типа "П 26" и так далее. И тут нет связи с длинной слова, а именно с частотой упоминания слова. Фраза "москва улица" будет искаться точно так же медленно, так как это частоупоминаемые слова и найдя все записи где хранятся оба эти слова ему придётся переоткрыть их все.

Третье: А что мешает прверить самому?

P.S. У меня была аналогичная задача. Я её решил просто: превратил адреса типа "П 26 248 01 00" в строку:
{П_26_248_01_00 П_26_248_01 П_26_248 П_26 П 26_248_01_00 26_248_01 26_248 26 248_01_00 248_01 248 01_00 01 00}
тоесть теперь адрес превращён в одно слово и есть все возможные варианты этого слова если человек будет искать любой его фрагмент.
А уже при выводе эта строка {...} меняется на привычное: Петроград, ул.Ленина 17-3
И если клиент будет искать: "Ленина 17" то система найдёт запись по слову 248_01

У меня ещё можно искать без улицы, проспекта, бульвара и т.д. Тоесть к фразам добавлены все варианты без _26_
{... П_248_01_00 П_248_01 П_248}
таким образом можно искать и "Петроград Ленина 17"

ЭтоИмяНеЗанятоInterSkyТы помнишь что если СЛОВО есть больше чем в 50% записей то оно является спамом? Твоя система запросто выкинет в мусорник такие слова как "П", "00", "01" и подобные, так как скорей всего они у тебя повторяются часто.

Если использовать natural mode то так оно и происходит, по подобным запросам ничего не выводится, но в boolean mode отрабатывает все так как надо.
В boolean mode будет нормально отоброжаться только если есть хоть одно неСПАМовское слово.
Потому что MySQL просто выкидывает из индекса спам-слова.
И если ты будешь искать фразу "П 00 01" (при этом все эти слова являются спамом), то системе для поиска придётся перебирать все 900 тысяч твоих записей (а это по времени займёт даже больше чем LIKE %...% (потому что надо найти не просто "П 00 01", но и "П-00-01", и "П! - 00,,,,{01}"), и я уже не помню как в таких ситуациях поступает MySQL:
- либо тратит несколько минут на поиск
- либо вообще просто говорит что такого результата нету, хотя он есть

InterSkyТретье: А что мешает прверить самому?

Уже проверил. Честно говоря, разницы в производительности не заметил. Поиск отрабатывает в среднем за 10-20 мс, примерно так он и при ft_min_word_len=4 отрабатывал.[/quot]
Совершенно предсказуемо для обычного текста.
Ведь в среднем у тебя наверно где-то около 50 тысячь слов в словаре (при длинне более трёх букв).
И в языке не так много слов длинной 1-3 буквы (даже тысячи не наберётся).
Но когда у тебя искуственный текст с добавлением всяких: i00, 3u3, dx7 и т.д., словарь может вырасти в тысячи раз .
Хотя 1000 это всего 2 в десятой степени, так что базе придётся всего на 10 сравнений сделать больше.


InterSkyP.S. У меня была аналогичная задача. Я её решил просто: превратил адреса типа "П 26 248 01 00" в строку:
{П_26_248_01_00 П_26_248_01 П_26_248 П_26 П 26_248_01_00 26_248_01 26_248 26 248_01_00 248_01 248 01_00 01 00}
Я думал о таком варианте. Мне он показался несколько извращенным и более костыльным, чем то, что есть сейчас, поэтому отказался.[/quot]
Зато так я могу найти адрес по городу улице и номеру дома (без уточнения будет это бульвар, улица, проспект или что-то другое).