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