Нет ли здесь специалистов по MySQL?

У меня проблема - слишком долго считается таблица MySQL с текстами.
Требуется определить, сколько раз в таблице встречается текст, содержащий 5 - 10 определённых слов. Таблица выглядит так:
CREATE TABLE IF NOT EXISTS tablename (
id INT(16),
txt TEXT,
PRIMARY KEY(ID)
)

Запрос выглядит так:

SELECT COUNT(id) FROM tablename WHERE txt LIKE '%слово1%' AND text LIKE '%слово2%' AND и так несколько раз.

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

А как дальше? Опять LIKE, только с цифрами вместо слов? Подозреваю, это не будет намного быстрее...

Причём чётко знаю, что phpBB как-то эту проблему решает, не зря же он строит индекс встречающихся слов...

Может, кто подскажет?

_________________
пишите на 'Max Brown'<mx@obninsk.ru>
(поскольку работает спам-фильтр)

я совсем не спец в MySQL (наоборот, только изучаю), но если ты осуществляешь поиск по полю txt логичным будет создать индекс этого поля. У тебя судя по приведенному виду таблицы его нет.

В Invision Power Board используется FULLTEXT индекс для поля post в котором хранится тело сообщения. В phpBB есть отдельная таблица для поисковых слов. Проще скачать phpBB и посмотреть как она создаётся и используется.

Далее может быть имеет смысл разбить запрос на несколько и объединить полученные результаты. Но не думаю что это добавит производительности.

Также на тему (нагуглил за 2 минуты):
http://dev.mysql.com/doc/refman/4.0/ru/ ... earch.html
http://www.opennet.ru/base/dev/mysql_pg ... h.txt.html
http://program.rin.ru/razdel/html/574.html

_________________
Михаил

Вот что значит пользоваться недоSQL базой данных. База данных в которой нет компиляции хранимых процедур - это просто набор таблиц. Это просто моё мнение....

далее в IBP используется SELECT MATCH ... AGAINST (...) для этого FULLTEXT индекс у столбца должен быть.

_________________
Михаил

Был бы это OR - можно было бы. Беда в том, что это именно AND и сделать финт типа a&b = !(!a|!b) тоже не получится.
А за ссылки спасибо.

_________________
пишите на 'Max Brown'<mx@obninsk.ru>
(поскольку работает спам-фильтр)

А какова альтернатива?

_________________
пишите на 'Max Brown'<mx@obninsk.ru>
(поскольку работает спам-фильтр)

Andrus, всё-таки, ответьте пожалуйста. Какие более быстрые базы данных проинсталлированы на хостинге Макснета, на каких тарифах они доступны, и если можно - где почитать о переходе на них с MySQL?
Я слышал, postgresql в несколько раз быстрее, но не знаю даже, есть ли PG на Макснете?

_________________
пишите на 'Max Brown'<mx@obninsk.ru>
(поскольку работает спам-фильтр)

Думаю, что на индигах альтернативы больше нет. И имхо для веба (странички, сайтики, форумы и проч.) MySQL вполне должно быть достаточно. В основном, быстродействия/функционала мускла кому-то мало из-за ошибок самих веб-программистов. Если вдруг посещаемость настолько большая или что-то нельзя реализовать на мускуле, то это уже встает вопрос о хостинге на отдельном серваке, куда можно поставить базу более подходящую для задачи.

_________________
Всё что ни делается - всё к лучшему

1. PG - не быстрее, PG более "фичастая" (хотя я начинаю слмневаться в этом читая changelog от mysql 5.1)

2. Хранимые процедуры в mysql есть, но они вам не помогут

3. Верное направление это fulltext index

кстати если данные прочитанной мною литературы не устарели, то индексы для запросов вида LIKE %слово ускорения не дадут. Хотя fulltext не знаю, не знаю... Лучше наверное использовать SELECT MATCH ... AGAINST (...) или строить какие-то дополнительные индексные столбцы/таблицы, особенно если слова запросов заранее известны.

P.S. упоминавшийся выше принцип используется в IPB 1.3. В 2.х возможно уже как-то по другому - не заглядывал.

_________________
Михаил

Индексирование текстовых полей думаю, в этом случае не поможет.
Вот если бы в запросе в место ЛАЙКА стоял знак РАВНО то другое дело.
А так мускулу придётся каждое текстовое поле просматривать и искать в нём слова. И индексация тут не причём. И хранимые процедуры более "продвинутых" баз тоже не спасут. Этот запрос просто смерть для сервака. На небольших объёмах он это ещё переваривать будет, а потом тушите свет. И в таком виде оставлять и делать ну ни как низя!
Правильно конечно, это при добавлении в таблицу очередной строки индексировать текстовое поле и пихать в другую таблицу полученные данные.

я что-то не пойму

_________________
Михаил

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

А во втором случае, и может быть я тут не совсем точно выразился. Имелось ввиду, что при добавлении строки в таблицу, надо подсчитывать, сколько и каких слов встречается в добавляемом тексте и обновлять на основе этой информации другую таблицу. Если этот процесс можно назвать, как то по-другому поправьте меня