Я обновил таблицу с myisam до innodb, но у меня не такая производительность. innodb возвращает оценку 0, когда должно быть какое-то отношение. Таблица myisam возвращает совпадение для того же термина (я сохранил копию старой таблицы, чтобы можно было выполнить тот же запрос).
SELECT MATCH (COLUMNS) AGAINST ('+"Term Ex"' IN BOOLEAN MODE) as score
FROM table_myisam
where id = 1;
Возвращает:
+-------+
| score |
+-------+
| 1 |
+-------+
но:
SELECT MATCH (COLUMNS) AGAINST ('+"Term Ex"' IN BOOLEAN MODE) as score
FROM table
where id = 1;
возвращается:
+-------+
| score |
+-------+
| 0 |
+-------+
Я думал, что ex, возможно, не был проиндексирован, потому что innodb_ft_min_token_size был установлен в 3. Я понизил это до 1 и оптимизировал таблицу, но это никак не повлияло. Содержимое столбца имеет длину 99 символов, поэтому я предположил, что весь столбец не был проиндексирован из-за innodb_ft_max_token_size. Я также увеличил это значение до 150 и снова запустил оптимизацию, но снова получил тот же результат.
Единственная разница между этими таблицами - это двигатель и набор символов. Эта таблица использует utf8, таблица myisam использует latin1.
Кто-нибудь видел это поведение, или у вас есть совет, как его решить?
UPDATE:
Я добавил ft_stopword_file="" к своему my.cnf и снова набрал OPTIMIZE TABLE table. На этот раз я получил
оптимизировать | примечание | Таблица не поддерживает оптимизацию, вместо этого выполняется воссоздание + анализ
Запрос сработал после этого изменения. Ex - не стоп-слово, хотя не уверен, почему это будет иметь значение.
Новый запрос, который не выполнен, хотя:
SELECT MATCH (Columns) AGAINST ('+Term +Ex +in' IN BOOLEAN MODE) as score FROM Table where id = 1;
+-------+
| score |
+-------+
| 0 |
+-------+
in приводит к сбою, но это следующее слово в моей таблице.
SELECT MATCH (Columns) AGAINST ('+Term +Ex' IN BOOLEAN MODE) as score FROM Table where id = 1;
+--------------------+
| score |
+--------------------+
| 219.30206298828125 |
+--------------------+
Я также пытался CREATE TABLE my_stopwords(value VARCHAR(30)) ENGINE = INNODB;, затем обновил my.cnf с innodb_ft_server_stopword_table='db/my_stopwords'. Я перезапустил и побежал:
show variables like 'innodb_ft_server_stopword_table';
который вернул:
+---------------------------------+---------------------------+
| Variable_name | Value |
+---------------------------------+---------------------------+
| innodb_ft_server_stopword_table | 'db/my_stopwords'; |
+---------------------------------+---------------------------+
поэтому я подумал, что in не приведет к сбою запроса сейчас, но он продолжается. Я также снова попробовал OPTIMIZE TABLE table и даже ALTER TABLE table DROP INDEX ... и ALTER TABLE table ADD FULLTEXT KEY ..., ни один из которых не оказал влияния.
Второе обновление
Проблема со стоп-словами.
$userinput = preg_replace('/\b(a|about|an|are|as|at|be|by|com|de|en|for|from|how|i|in|is|it|la|of|on|or|that|the|this|to|was|what|when|where|who|will|with|und|the|www)\b/', '', $userinput);
решает проблему, но это не кажется мне хорошим решением. Мне бы хотелось, чтобы решение, которое не использовало стоп-слова, нарушало бы это в mysql.
Данные таблицы стоп-слов:
CREATE TABLE `my_stopwords` (
`value` varchar(30) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
и
Name: my_stopwords
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 0
Avg_row_length: 0
Data_length: 16384
Max_data_length: 0
Index_length: 0
Data_free: 0
Auto_increment: NULL
Create_time: 2019-04-09 17:39:55
Update_time: NULL
Check_time: NULL
Collation: latin1_swedish_ci
Checksum: NULL
Create_options:
Comment: