博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
数据库like匹配的实现猜测
阅读量:6515 次
发布时间:2019-06-24

本文共 1054 字,大约阅读时间需要 3 分钟。

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

转载于:https://www.cnblogs.com/wangtao_20/p/3539922.html

你可能感兴趣的文章
利用SMB jcifs实现对windows中的共享文件夹的操作
查看>>
Spring(十七):Spring AOP(一):简介
查看>>
html5常用属性text-shadow、vertical-align、background如何使用
查看>>
微软正式宣布Azure MongoDB Atlas免费方案
查看>>
Jessica Kerr:高绩效团队简史
查看>>
开发者需要知道的有关软件架构的五件事
查看>>
GitLab 9提供了子群组、部署面板和集成监控
查看>>
继爆款超级账本后,IBM再次推出新产品
查看>>
贝壳金控赵文乐:基于 Spring Cloud 的服务治理实践
查看>>
Pyspider框架 —— Python爬虫实战之爬取 V2EX 网站帖子
查看>>
区域生长算法 C++实现
查看>>
数据分析-从入门到崩溃
查看>>
web.xml 中的listener、 filter、servlet 加载顺序
查看>>
MyBatis原理简介和小试牛刀
查看>>
js部分基础
查看>>
Docker 常用基础命令
查看>>
脏读,幻读,不可重复读解释和例子
查看>>
Day02 数值运算&条件判断
查看>>
Tomcat指定(JDK路径)JAVA_HOME而不用环境变量
查看>>
Bluemix专属版本落地中国 开放物联网和认知计算能力
查看>>