как оно 4.х ветка ?
можно уже использовать и какие вкусности там есть ?
если кто юзал и\или переезжал с 3.х ветки, скажите + и - пожалуйста

normalno rabotaet daje 4.1 ;) vse rulit, 2 mesyaca uje rabotaet, load ne ochen bolshoy.. no stabilno vse :)

Ага.. 4.1 "работает"... большие таблицы FULLTEXT index'ом крашаются через раз.. если не каждый раз. На маленьких все ок.

Заметно выросла скорость с применением querycache. На стабильность не
жалуемся. Аптайм по полгода и выше. Прерывается только обновлениями.

Я бы не рекомендовал использовать FULLTEXT index на чем-то серьезном.
Не из-за крашей, а из-за ограниченных возможностей. Впрочем, любой
разработчик и сам это обнаружит очень быстро.

А чем ты предлогаешь пользоваться? Без индекса слишком медленно ищет.

Fixed crash of FLUSH QUERY CACHE on queries which use same table several times (BUG#988).

ура, вот этот баг как раз был очень неприятен, и из-за него я query cache отключал.

А с вложенные запросы не используете, как они в 4.1 ?

>Ага.. 4.1 "работает"... большие таблицы FULLTEXT index'ом крашаются через раз.. если не каждый раз. На маленьких все ок.

da.. est' takaya ficha... fulltext tolko ne uzayu, no na odnoy baze takoe cherez raz.. klient ne dovolen :)

Большие это скока записей ? У меня небольшие (порядка 200K) нормально пашут.

Пользоваться своим индексатором, конечно...

Подскажите где брать патчи, а то на сайте одни редиректы на сам релиз

Мускуль СОСЕТ! PostgreSQL FOREVER!

Ну вот, а поддержку обсчета матрицы альфа-коэффициентов для морфирования темплейтов так и не сделали, хотя собирались еще к прошлому релизу.

>Ага.. 4.1 "работает"... большие таблицы FULLTEXT index'ом крашаются >через раз.. если не каждый раз. На маленьких все ок.

Хм. А в чем проблема конретно? У нас на 10Mb таблицах не возникало проблем с FULLTEXT. Надо учитывать, что MySQL была перекомпилена без учета стоп слов.

Быстро работает :-)

Инфа взятая из status

Threads: 5
Questions: 12935578
Slow queries: 56
Opens: 120
Flush tables: 1
Open tables: 114
Queries per second avg: 49.759

Это разве много ? У нас и в 100 раз больше запросов в секунду бывает

А может не стоит использовать 4.1 который еще АЛЬФА.
И ругать из-за этого стаблиный 4.0

Тогда глупый вопрос (без заковырки - нужно для дела) - есть ли готовые алгоритмы? И где почитать про это?

И, по-моему, единственным значимым, ограничением FULLTEXT поиска сейчас является ограничение на длину слова - более трёх знаков... Или я что-то пропустил?

>И, по-моему, единственным значимым, ограничением FULLTEXT поиска сейчас является ограничение на длину слова - более трёх знаков... Или я что-то пропустил?

Длина слова регулируется переменной ft_min_word_len не забудьте переиндексировать таблицу если измените эту переменную

Re:

2 anonymous (*) (23.10.2003 13:04:41) А не подскажешь как компилил + что в my.cnf нарисовано? А то у меня прим. 150 запросов в сек. и раз в сутки валится...:(

Спасибо, но это я знаю. Только ни одного хостера не убедишь перекомпилировать из-за тебя (меня то есть =) MySQL.

А так ли уж плох FULLTEXT поиск? Или кроме ограничения длины слова с ним всё в порядке?

2 xlex
Она прописываеться my.cfg в секции mysqld
А не в сорцах.

У меня сейчас в базе почти два гига. Пашет нормально, но периодически приходится чинить, а то и восстанавливать из бэкапа :-(

Спасибо. А имеет смысл уменьшаеть это значение до одного, или от этого что-то сломается (скорость/размер индекса/...)?

Чинить и прочие кошмары - это из-за чего?

А на слаке пойдёт?

> Чинить и прочие кошмары - это из-за чего?

А хез. Обычно заявляет, что индекс поврежден у одной из таблиц базы.
Обычно же после фикса проблема исчезает.
Разок самую важную таблицу запорола (впрочем это было давненько и, вероятно, это была еще 3шка) - пришлось восстанавливаться.

Последний раз порола индекс буквально позавчера.
Нафик эту mysql. Перейду для начала на postgresql при первой же возможности (пока слишком многое завязано на ЭТО).

И вас вылечат ;o)

Просто так никакие индексы не рушатся. Вот если на серваке reset нажать во время работы - то да, попадает все.

> Тогда глупый вопрос (без заковырки - нужно для дела) - есть ли готовые алгоритмы? И где почитать про это?

Где читать - не знаю. Мне нужна была индексация для конкретной задачи.
Я экспериментировал с FUULTEXT INDEX. Не прошло. И вот почему. У меня
частые обновления базы. С индексом они идут медленно. Без него - останавливается поиск на время обновления. Далее, FULLTEXT INDEX заточен
скорее под поиск в статьях и книгах. У меня прайс-листы с товаром.
Понятие "word" в этом индексе не совсем соответствует тому, что мне
надо. Коды и модели часто пишутся с разными разделителями. Это надо
учитывать. Стоп-слова там вообще не нужны. Ограничение на длину тоже не
нужно. В ранних версиях это дело не настраивалось. Короче, оказалось
проще написать свой индексатор, который создает отдельную таблицу.
Индексатор включается после каждого добавления, и создается во временной
таблице, которая переименовывается в основную после завершения
индексации. Работает довольно быстро. 10-15 сек на 300тыс записей со
средней длиной текстового поля 150 символов.

Еще в FULLTEXT INDEX мне не подходит их понятие "highest relevance".
В-общем, вещь в себе. Совершенно не гибкая в настройке и недоделанная.

Если возможно, я хотел бы ещё задать пару вопросов по алгоритму, по email-у: мой - xlexATfromDOTcom, либо куда мне можно написать?

Алгоритм мой тебе не поможет. Он настроен под задачу. Экспериментируй.