Вопрос часто встречается, но почему-то в поиске толком ничего не нашёл.

Нужно осуществить поиск по базе.
Два поля: VARCHAR (255), TEXT.

Оптимален ли будет такой запрос:

SELECT
C.name, C.descr,
MATCH (name, descr) AGAINST ('word1') + MATCH (name, descr) AGAINST ('word2') As R
FROM sites C
WHERE (MATCH (name, descr) AGAINST ('word1')) OR (MATCH (name, descr) AGAINST ('word2'))
ORDER BY R DESC;

Ну, там могут добавиться ещё word3, word4...

Может быть, использовать для этой цели TEMPORARY TABLE, как это описано тут:
Поиск по двум ключам




Также не кинете ссылку или не опишете, как сделать поиск по части слова (а не по всему, как это сделано в моём запросе). Есть что-то быстрее, чем LIKE по каждому слову и затем соединение результатов всех этих запросов?

Можно создавать MemotyTable - будет оч. быстро...
Можно индексировать поля поиска... Тогда и Like будет работать быстро...

А как индексировать?
Просто CREATE INDEX не применяется к полю TEXT, использовать CREATE FULLTEXT INDEX?

Он LIKE убыстряет?

Код

ALTER TABLE `cites` ADD FULLTEXT `fulltxt` ( `descr` (255) )

Like вроде как должен быстрее работать... Насколько я знаю...
AFAIK LIKE работает с индексированными полями несколько иначе, чем с неидексированными... Ведь индексы в таблице упорядочены... А значит и поиск по ним ведется быстрее...

Это сообщение отредактировал(а) Kesh - 18.1.2005, 01:20

1. Расскажи ламеру, что такое (255) у тебя в скобочках?
У меня descr может содержать до неск. килобайт текста.

2. Я смотрю по логике. Если индекс просто упорядочивает строки, то LIKE быстрее раотать не должен. Вот если он не просто по алфивиту их выстраивает, а что-то ещё особенное делает...
Но, в принципе, у меня нагрузка будет не очень большая на базу, так что...

Ты же сравниваешь TEXT с varchar(255)... отсюда и длина индекса... другое дело, если ты делаешь полнотекстовый поиск... тут уже 255 не нужно...

Like быстрее работать и не будет... просто для сравнения строки будут выбираться быстрее... т.к. будут упорядочены...

Цитата(Kesh @ 18.1.2005, 01:43)

Ты же сравниваешь TEXT с varchar(255)...

Я сравниваю два поля - name varchar (255) и descr text со строкой, которую ввёл пользователь.


Тогда я делаю LIKE по каждому слову и затем слепляю полученные результаты, так?
А нет более-менее нетормознутой возможности посмотреть, сколько раз входит слово в текст? Хочется сделать что-то типа сортировки по релевантности...


Это сообщение отредактировал(а) dm9 - 18.1.2005, 01:55

Цитата(dm9 @ 18.1.2005, 01:51)

сортировки по релевантности...

Так ведь MATCH - AGAINST так и работает...

Я говорил про LIKE

Ладно, я уже сделал некое подобие поиска.

Делаю SELECT ... LIKE по каждому слову и запихиваю данные в промежуточную таблицу (с двумя полями - id и rel - релевантность), причём за попадание слова в name даю два очка, если в descr - одно. Затем SELECT SUM(rel) As rel, ... FROM tmp ... GROUP BY id ORDER BY rel - и я счастлив... по крайней мере, пока база не очень большая.

Это сообщение отредактировал(а) dm9 - 18.1.2005, 05:04

http://www.mysql.ru/docs/man/Fulltext_Search.html
Вот здесь рассказано про полнотекстовый поиск... и про релевантность...
Так что похоже ты с самого начала делал правильно...

Это сообщение отредактировал(а) Kesh - 18.1.2005, 23:25

Я это читал

Вот только:

Простой полнотекстовый поиск - только по всему слову целиком. Зато с релевантностью.

IN BOOLEAN MODE - без релевантности. Везде выдаётся единичка. И вариации возможны только в конце слова, начало фиксированное.

Я сейчас сделал так.
Релизовал два поика. Первый - LIKE-ом, второй IN BOOLEAN MODE. Когда начнёт торозить LIKE, надо будет закомментировать одну строчку и поиск теоретически должен работать быстрее.

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

dm9ОК, обязательно сообщи результаты...

Везде будет приведено время выполнения скрипта. То есть это чуть больше, чем время запроса к БД.
Если это принципиально - машина Athlon 2,26 GHz, ОП - 512 MB.

LIKE проводился по каждому слову по каждому полю (name, descr) отдельно, результаты - в промежуточную таблицу, затем из неё SELECT.

IN BOOLEAN MODE - использовался один запрос вида MATCH (name, descr) AGAINST('word1* word2* word3* и так далее' IN BOOLEAN MODE).
Естественно, вначале был выполнен запрос CREATE FULLTEXT INDEX schidx ON sites (name, descr)

name - 64 байта.
description - 1000 байт.

Записей чуть больше ста (итого размер данных, по которым проводится поиск, около 110 КБ ).
Поиск по 1 слову, встречающемуся почти во всех записях
LIKE: 0.06 - 0.07
IN BOOLEAN MODE: 0.04

Записей чуть больше тысячи (итого размер данных, по которым проводится поиск, около 1,1 МБ ).
Поиск по 1 слову, встречающемуся почти во всех записях
LIKE: 0.20 - 0.28
IN BOOLEAN MODE: 0.16 - 0.22

Записей чуть больше десяти тысяч (итого размер данных, по которым проводится поиск, около 11 МБ ).
Поиск по 1 слову, встречающемуся почти во всех записях
LIKE: 2.0-4.0
IN BOOLEAN MODE: 1.4 - 1.7
Поиск по 2 словам, встречающимся почти во всех записях
LIKE: 3.5-4.0
IN BOOLEAN MODE: 3.3 - 3.4
Поиск по 5 словам, встречающимся почти во всех записях
LIKE: 7.0-8.0
IN BOOLEAN MODE: 4.8 - 5.0
Поиск по 1 слову, НЕ встречающемуся в записях
LIKE: 2.5-3.0
IN BOOLEAN MODE: 0.02 - 0.03

В общем, тенденция понятна, ещё тесты проводить мне в лом.

И ещё. Возможно, что-то можно сделать быстрее, если написать попрямее скрипт...

Это сообщение отредактировал(а) dm9 - 19.1.2005, 04:32

Спасибо за инфу...