MySQL 全文搜索

今天我的表现,优化速度较慢 SQL 请求类型

SELECT * FROM 'table' WHERE `field` LIKE '%word%'

在哪里是麻烦一时刻在这里吗 – 最后一部分词 %‘ %’ 甚至在更大的具体性字符 % 一词之前, 为此我们做. 通配符 % ,以前的任何值, 我们的应用程序直接转化为直接慢, 因为这种方式在应用程序停止我们要使用的索引. 与往常一样有解决方案, 但并不总是明确 😆 一般 MySQL 你有解决这个问题 全文搜索 索引的. 如何是场有变化的是大量写在文档中, 但在匆忙中我将描述如何更改最高的要求, 因为我们会拿到一个小型戏剧最后. 弥补可爱适用于全文字段, 查询需要在表单中更改:

SELECT * FROM `table` WHERE MATCH (field) AGAINST ('word')

所以结构是明显和不必要的讨论没有必要. 上面的查询将生效, 如果这个词, 为此你都至少做一个请求 4 符号, 这是默认值, 如果你想要修改它,您必须指定的值, която желаете в my.cnf в частта [mysqld] 与宣言 》 ft_min_word_len= 3 或 2, 1 не е добър избор очевидно 😉 . 之后您更改的值并重新启动 mysql 服务器需要做修复表, 为了使新的索引开始生效. 在这里所有清除: 你换吗, 重置, rebildvam 指数,使我的请求和返回 0 检查线与 😀

SHOW VARIABLES

我看到的值, 我问过已生效, rebildvam 指标再次 – 同样的结果. 🙄 恨, 很不舒服. ОТ ТУК НАТАТЪК ЗАПОЧНА ЕДНО ГОЛЯМО РУГАЕНЕ И РОВЕНЕ ЗА КЛЮЧА ЗА БАРАКАТА 😀 КОЙТО СЕ ОКАЗА ДОСТА, ДОСТА ИНТЕРЕСЕН. КАТО ЦЯЛО, КАТО ЗАПОЧНАХ ДА ЧЕТА ДОКУМЕНТАЦИЯТА ЗА Н ЗНАМ КОЙ ПЪТ И СТИГНАХ ДО ЕДИН ИНТЕРЕСЕН ПАСАЖ

Such a technique works best with large collections (事实上, 它是仔细的调整这种方式). 对于非常小的表, 词分布并没有充分反映它们的语义价值, 和这种模式有时可能产生奇怪的结果. 举个例子, 虽然单词"MySQL"目前在早些时候所示的文章表的每一行, 搜索词未产生结果

ГРЕДА 😳 Дам табличката ми беше малка – 它仍然是一次考验. 在一个大型应用程序 Naših 表的结束 2 000 000 秩序和那些东西是睡着了. 很好已经明显问题. 要弄清楚的解决方案, 我将简略地, 全文搜索支持 3 高级的模式 布尔值 , 表达式自然语言 默认情况下的最后作品. 有关不同的模式,您可以检查文档, 我会解释与 2-3 词语为布尔型,因为它是关键. 它支持逻辑运算符的类型和, 或 , 不,等等,可以使一些魔术与搜索短语, 有, 还有另一个,等等。. 支持和符号 *, 这就是相当于通配符字符 % 😉 很有用, 搜索词时的长度 ft_min_word_len 或小托盘 ;). 至少对我的同桌 100 线做一个完美的工作. 唯一留给见和完成的应用程序:

SELECT * FROM `table` WHERE MATCH (field)
AGAINST ('*word*' IN BOOLEAN MODE)

现在来了一段时间与我们通配符字符索引工程 – 答案是我不知道. Принципно мисля, че да, защото не е казано друго в документацията, но в документацията очевидно не се казват или показват много неща 😀

通过增强Zemanta

2 comments

    1. Е при големи таблици вече има други решения 😉 partitions да речем или други механизмни за fulltext search като Sphinx

发表评论

您的电子邮件地址不会被公开. 必需的地方已做标记 *

反垃圾邮件 *