MySQL Match Against IN BOOLEAN MODE

[andrik9191]

Не можу зрозуміти як працює мій запит, і треба його справити бо він очевидно працює неправильно.
Маю наступну таблицю:

CREATE TABLE IF NOT EXISTS `site_catalog_prices` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `page_id` int(10) unsigned NOT NULL DEFAULT '0',
  `element_id` int(10) unsigned NOT NULL DEFAULT '0',
  `sortorder` int(10) unsigned NOT NULL DEFAULT '0',
  `price` float NOT NULL DEFAULT '0',
  `currency` int(10) unsigned NOT NULL DEFAULT '1',
  `descr` varchar(255) DEFAULT NULL,
  `art_n` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `page_id_2` (`page_id`,`element_id`),
  FULLTEXT KEY `ft_descr` (`descr`,`art_n`)
) ENGINE=MyISAM  DEFAULT CHARSET=cp1251 AUTO_INCREMENT=11336 ;

Маю наступний запит до бази:

SELECT c.id, p.descr, p.art_n 
FROM site_catalog_prices as p 
INNER JOIN site_catalog as c on c.id=p.element_id 
INNER JOIN site_pages_tree as t on t.id=c.page_id 
WHERE     MATCH(p.descr,p.art_n) AGAINST ('"MT/153-1" MT/153-1*' IN BOOLEAN MODE) 
        and c.hide=0 
        and t.hide=0 
GROUP BY c.id LIMIT 50

На сайті вводиться ключова фраза MT/153-1

результат запиту


в результатах пошуку є не те що треба, а того єдиного результату пошуку який обовязково має бути немає



очевидно що вся суть цього пошуку в цій частині
WHERE MATCH(p.descr,p.art_n) AGAINST ('"MT/153-1" MT/153-1*' IN BOOLEAN MODE)

якщо щось не вказав все додам, буду дуже вдячний за допомогу

[castor]

класика жанру - пошук не працює, бо він не індексує правильно твої слова, тому що сприймає символи "/" та "-" за розділювачі слів

рішень купа, просто перерахую їх в порядку "правильності"

1) перенести повнотекстовий пошук на sphinx - http://sphinxsearch.com/docs/current.html
Мінуси
- треба з ним розібратись;
- поставити додаткову програму - вимагає рутового доступу до сервера, без нього ніц не буде;
- зв'язати докупи sphinx та mysql;
- поновлення даних у самому sphinx не є міттєвим, хоча і відбувається досить швидко (на тестовій дохлій системі 600 тисяч записів поновлювало за 1-2 хвилини - це швидше, ніж сам mysql створював повнотекстовий індекс на тих же символьних колонках)

А також конвертнути всі таблички, які приймають участь у пошуку, в utf8 (це важко вважати мінусом).

Все решта - плюси:
- можна налаштувати так, щоби sphinx сприймав твої слеші і мінуси, як легальні символи;
- пошук адекватний і релевантний;
- працює непристойно швидко;
- повнотекстовий пошук сам по собі набагато гнучкіший.


2) шукати такі поодинокі записи за допомогою LIKE - у скрипті визначати, чи потрібен тобі повнотекстовий пошук, чи можна обійтись LIKE-ом
Не забуваємо, що штуки типу "LIKE '%string%'" не використовують ніякі індекси, а тому реально тормозять.


3) переналаштувати пошук на самому mysql, щоби сприймав слеші та мінуси - тобі повезло, бо цей спосіб якраз працює добре з 1-байтовими символами і (дуже) погано працює з юнікодом
Документашка тут - https://dev.mysql.com/doc/refman/5.7...collation.html
Точно не скажу, але здається, що ця штука працює, починаючи з mysql 5.6.
Ну і само собою, треба рутовий доступ до сервера.


4) "поміняти алфавіт" - якщо треба шукати по слешах, мінусах і т.п. чарівних символах, то вилучити їх з полів, замінивши на щось інше, що сам mysql буде сприймати як слова, а не розідлювачі
Наприклад, щось тіпа такого - завести окремі пошукові поля ft_descr та ft_art_n, куди писати значення з відповідних полів, але заміняючи слеші та мінуси на SYM_SLASH та SYM_MINUS. І не забувати, коли міняються значення полів descr та art_n, міняти їх відповідники ft_descr та ft_art_n.
Тоді при пошуку шукати з MATCH по ft_descr та ft_art_n і не по введеному рядку, а також замінити у ньому слеші та мінуси на ці слова.
Цей спосіб я не пробував, тому там можуть бути свої нюанси.


ЗІ цікаво, що заставляє людей у 2017 році використовувати MyISAM та cp1251?

[andrik9191]

дякую за поради, треба буде подумати над вибором варіанту)

> цікаво, що заставляє людей у 2017 році використовувати MyISAM та cp1251?
цей не мій проект, попросили глянути чому не працює пошук