Как правильно разрулить FULLTEXT с типом таблиц InnoDB 2.X

Возникают проблемы с поиском, с открыванием фото и др.

 
Посетитель
small user social cms
МедальПочетный донор проектаАвторитет форума
Сообщений: 2250
Началось с того, что обратил внимание на отказ фото открываться в фотоальбоме! Не хочет не только открываться на весь экран, но бывает не открываются даже в первое положение (когда открывается доступ к скачиванию).
Причем проблемы с фотоальбомом сопровождались ошибкой базы

[spoiler=Ошибка базыНевозможно отыскать полнотекстовый (FULLTEXT) индекс, соответствующий списку столбцов

SELECT i.*, MATCH(i.title) AGAINST ('>\"Дети\" <(дети)' IN BOOLEAN MODE) as `fsort`, u.nickname as `user_nickname`, u.is_deleted as `user_is_deleted`, u.avatar as `user_avatar`
FROM cms_photos i
INNER JOIN cms_users as u ON u.id = i.user_id
INNER JOIN cms_con_albums as al ON al.id = i.album_id
WHERE (i.id <> '14') AND (MATCH(i.title) AGAINST ('>\"Дети\" <(дети)' IN BOOLEAN MODE)) AND (i.is_private = '0') AND (al.is_approved = '1')
ORDER BY fsort desc
LIMIT 20[/spoiler]

С помощью Ris'а выяснилась закономерность, что если таблица cms_photos имеет тип MySam то все работает, а если InnoDB, тогда и начинаются проблемы! Вспомнил, что InnoDB не работают с FULLTEXT (а ведь этих индексов полно по базе, устанавливаются по умолчанию). Меняю индекс FULLTEXT на простой INDEX (в таблице индексов FULTEXT поменялся на BTREE) и фотографии начали открываться и при InnoDB!!!

Казалось бы проблема решена, но попробовав Поиском найти фото, опять столкнулся с проблемой (FULLTEXT) индекс! такая же проблема с Поиском возникает и с другими таблицами, если в них изменить FULLTEXT на INDEX/

Создается парадоксальная ситуация, когда База с типами таблиц InnoDB лучше работает без индексов FULLTEXT, но сам скрипт не может без них жить! Держать часть таблиц в MySam, а остальные в InnoDB не самая лучшая практика, теряется скорость работы и сложнее настроить конфигурацию MySQL

Вопрос к знатокам Как правильно разрулить FULLTEXT с типом таблиц InnoDB или что надо сделать, чтобы движек сайта нормально работал без индексов FULLTEXT?
Лучшее место для вашего сайта!
Посетитель
small user social cms
МедальПочетный донор проектаАвторитет форумаКубок зрительских симпатийПочетный донор проекта
Сообщений: 2551
на сайте
Интересненько. Посижу послушаю.
Тем более в инсталляторе последней (2.11.0) версии рекомендуется выбирать InnoDB (раньше рекомендовалось MyISAM)...
Виджеты, поля и компоненты для instantcms 2 http://www.zau4man.ru/
Реклама
cms
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатий
Сообщений: 3545
В MySQL 5.6.4 вроде порешали вопрос с полнотекстом https://dev.mysql.com/doc/refman/5.6/en/innodb-fulltext-index.html
Возможно просто сами полнотекстовые индексы не объявлены в вашей бд. На 2.11.0 у кого-то я уже чинил базу и там не хватало индекса на title, хотя там был индекс (title, content). Проявлялось это именно в фотках и поисковике.
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатийПочетный донор проекта
Сообщений: 2644
Loadырь,
Проводим эксперимент.
Ставим чистую INSTANTCMS2.11.0 на опенсервер. Модуль mysql - mysql5.8 (8.0.12).
Смотрим енджайн таблиц:
Спойлер
Видно без очков, что таблицы имеющие FULLTEXT индекс остались в MyISAM.
Таблица cms_photos тоже.

Далее конвертим cms_photos в InnoDB.
Тут же получаем характерную ошибку:
Ошибка в запросе БД:
Спойлер
Мысль такая, что фултекст на InnoDB работает как-то не так, как на MyISAM.
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатий
Сообщений: 3545
Ris, после перевода на InnoDB добавьте полнотекстовый поиск ещё на title и посмотрите как будет работать.
у вас в запросе "MATCH(i.title)" такого индекса нет, есть на (title, content). добавьте на (title) и посмотрите
Редактировалось: 1 раз (Последний: 21 января 2019 в 19:30)
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатийПочетный донор проекта
Сообщений: 2644
Loadырь:
Ris, после перевода на InnoDB добавьте полнотекстовый поиск ещё на title и посмотрите как будет работать.
у вас в запросе "MATCH(i.title)" такого индекса нет, есть на (title, content). добавьте на (title) и посмотрите
Да, помогло.
Я где-то слышал, что в InnoDB MATCH требует полного соответствия полей, перечисленных в индексе.
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатий
Сообщений: 3545
Ага и только что в этом убедились
Посетитель
small user social cms
МедальПочетный донор проектаАвторитет форума
Сообщений: 2250
Loadырь:
такого индекса нет, есть на (title, content)
этот индекс означает поиск одновременно по двум полям!
Loadырь:
Зачем создавать повтор, пусть даже с одним полем для поиска?
Лучшее место для вашего сайта!
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатийПочетный донор проекта
Сообщений: 2644
vikont:
Зачем создавать повтор, пусть даже с одним полем для поиска?
Затем, что
Ris:
в InnoDB MATCH требует полного соответствия полей, перечисленных в индексе.
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатий
Сообщений: 3545
vikont:
Зачем создавать повтор, пусть даже с одним полем для поиска?
Можно делать не повтор, а отыскать и поправить запрос в БД на MATCH(i.title, i.content), тогда всё будет чётко smile
Посетитель
small user social cms
МедальПочетный донор проектаАвторитет форума
Сообщений: 2250
Ris:
Ris:
в InnoDB MATCH требует полного соответствия полей, перечисленных в индексе.
Вот и получается, что на каждый запрос надо свой индекс
Например в таблице cms_con_albums для работы с фотками нужен индекс (title), а поиск уже требует (title, content) делаем второй индекс и перестают работать фотки... и какой отсюда выход?
Лучшее место для вашего сайта!
Посетитель
small user social cms
МедальПочетный донор проектаАвторитет форума
Сообщений: 2250
Loadырь:
Можно делать не повтор, а отыскать и поправить запрос в БД на MATCH(i.title, i.content), тогда всё будет чётко
И так перелопатить весь движок Инстанта.... где б столько мозгов взять... facepalm
У Fuze не займешь, заняты на 200%...
Получается движек еще не полностью готов к 100% переходу на InnoDB
Редактировалось: 1 раз (Последний: 21 января 2019 в 20:08)
Лучшее место для вашего сайта!
Посетитель
small user social cms
МедальАвторитет форумаКубок зрительских симпатийПочетный донор проекта
Сообщений: 2644
vikont,
Да повесьте Вы еще один индекс. Вам жалко что ли?
Посетитель
small user social cms
МедальПочетный донор проектаАвторитет форума
Сообщений: 2250
Ris:
vikont,
Да повесьте Вы еще один индекс. Вам жалко что ли?
Вы читали выше? Повесил и фотки уже не открываются.
Лучшее место для вашего сайта!
Посетитель
small user social cms
МедальПочетный донор проектаАвторитет форума
Сообщений: 2250
Пришло время пояснить за что боремся.....
Мой VPS имеет вебсервер NGINX+php-frm+MariaDB 10.3.7 базы с таблицами InnoDB
Это дало снижение загрузки самых тяжелых страниц (при не загруженном сервере) до 0,8 сек, при повторном обновлении страницы , до 0,7 сек, при обновлении страницы со сбросом кеша (CTRL+F5), до 0,6 сек!
А вот когда удаляются индексы FULLTEXT, то эти показатели падают еще минимум на 0,1 сек. Легкие страницы грузятся вообще с 0,08ххх и меньше.

Кроме этого, когда все таблицы типа innoDB сама база работает быстрее и более корректно, как в мужском коллективе, а смешанная база ... это как коллективе появилась хотя бы одна женщина... laugh И управляется тяжелее и работает не предсказуемо.

Вот такие аргументы в пользу InnoDB и Fuze не зря сделал ставку на него.
Лучшее место для вашего сайта!
В начало страницы
Предыдущая темаСледующая тема Перейти на форум:
Быстрый ответ
Чтобы писать на форуме, зарегистрируйтесь или авторизуйтесь.