数据库like匹配的实现猜测



insert into test_fulltext values("王正科技全文")


select * from test_fulltext where data like "%王正%"


能够搜索到新插入的一行数据。

data字段并不是全文索引字段。


其实反而不要使用match against去搜索,也就是不要使用全文搜索,使用全文搜索的话,会进入全文索引结构中去寻找数据。而刚好mysql对中文分词支持存在问题。所以mysql全文索引中建立的词典索引中不存在那个词语,比如

select * from test_fulltext where MATCH(data) AGAINST(‘王正‘IN BOOLEAN MODE )

提示此表不支持全文索引,也就是没有建立成全文索引

 

 

读者若有什么更好的看法,欢迎讨论


ALTER TABLE `test_fulltext`
ADD FULLTEXT INDEX `idx_data` (`data`) USING HASH ;

BTREE

上面都错误,正确sql为:

ALTER TABLE `test_fulltext` ADD FULLTEXT (
`data`
)

因为全文索引不存在使用btree还是hash方式进行索引。就是一个词典,何来这种索引?



建立成全文索引后,使用

select * from test_fulltext WHERE MATCH(`data`) AGAINST(‘王正‘IN BOOLEAN MODE)

搜索不到


使用王正反而更加能够搜到到。

结论:like这种搜索,是全表扫描。是对字段中出现的内容全部进行匹配。相等匹配。不是不可以,就是效率低下,当数据量大的情况下很慢

数据库的实现思路可能为:逐个扫描所有行,然后拿到字段的内容。比如拿到了此行data字段的内容,然后把内容当成一个字符串去里面查找是否有出现过的词语

类似于 php的代码实现
if(strpos($data字段内容,要查找的字符串))!==false)
{
找到了字符串
}



like匹配是基于字符串的匹配(%就是对应正则匹配,也是字符串配对),这样的方式需要扫描表的所有行,拿到每行的内容进行字符串匹配。其实我的理解是:最大瓶颈就是需要全表扫描。至于里面的%正则匹配倒不是很大问题,这里速度不会成为瓶颈,反而全表扫描耗费是时间比较长是一个大问题。

数据库like匹配的实现猜测,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。