Обходной путь полнотекстового поиска MySQL для таблиц innoDB

Question

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

Я хочу выполнить полнотекстовый поиск записей одного типа, которые изначально не поддерживаются в таблицах innoDB. Я не хочу переходить на MyISAM таблицы из-за отсутствия поддержки внешнего ключа и из-за того, что их блокировка выполняется для таблицы, а не для строки.

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

Или это неудобный способ сделать это, которого следует избегать?

Спасибо.

Answer 1

Возможно, вы сможете выполнить некоторую синхронизацию данных с помощью триггеров (если ваша версия mysql поддерживает их). Они позволяют запускать небольшие фрагменты SQL-кода в определенные моменты, например, после вставки или удаления данных из таблицы.

Например ...

create trigger TRIGGER_NAME after insert on INNODB_TABLE
insert into MYISAM_TABLE select * from INNODB_TABLE
where id = last_insert_id();

... Всякий раз, когда данные вставляются в таблицу INNODB, эти же данные автоматически вставляются в таблицу MYISAM.

Answer 2

Я думаю, это действительно неловко. Тем не менее, мой метод «быстрого прототипа, который, вероятно, случайно станет рабочим кодом», выглядит примерно так:

CREATE TEMPORARY TABLE search_mirror (FULLTEXT INDEX (col1, col2, ...)) Engine=MyISAM SELECT * FROM original_innodb_table;

SELECT * FROM search_mirror WHERE MATCH(col1, col2, ...) AGAINST ('foo');

DROP TEMPORARY TABLE search_mirror;

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

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

Answer 3

Вы можете создать зеркальную таблицу. Это, вероятно, не идеально, поскольку таблица MyISAM не будет учитывать ваши транзакции (если транзакция не удалась на InnoDB, ваши изменения, сделанные в MyISAM в этой транзакции, все равно будут отображаться).

Вы можете использовать выделенную систему полнотекстового поиска, такую ​​как Sphinx , которую я использовал для полнотекстового поиска (поскольку моя база данных - InnoDB).

Answer 4

Хорошие новости! В MySQL 5.6 и выше полнотекстовые индексы могут использоваться с таблицами InnoDB. Вам следует рассмотреть возможность обновления MySQL до 5.6 или выше, если вы еще этого не сделали.

В моем приложении полнотекстовый поиск был очень важен, поэтому я просто использовал MyISAM. Теперь я обновил MySQL до 5.6, преобразовал базу данных в InnoDB и добавил правильные ограничения. Лучший из беспокойных миров.

MySQL 5.6 Manual - Функции полнотекстового поиска

Answer 5

Мне кажется, что простейшим решением этой проблемы является создание индексной таблицы, которая будет использоваться для поиска, с указателем на таблицу, которая содержит реальные данные. У меня точно такая же проблема, и я не хочу использовать таблицы MyISAM для своей системы из-за душевного спокойствия, данного таблицами InnoDB.

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

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