MySQL 全文检索 实现中文检索
通过MySQL内置全文检索实现中文的相关检索
关键字:MySQL 全文检索 全文索引 中文分词 二元分词 区位码 相似度
注:本文使用的MySQL版本为:MySQL 4.0.x
在MySQL4中,是已经开始支持全文检索(索引)的了。但是只是对英文支持全文检索。
由于英文在书写上的特殊性,使得分词算法相对中文来说,简单得多。一般来说,我们可以通过单词与单词之间的空格,以及标点符号来完成这个分词过程。
但是就中文来说,就没有那么简单。MySQL无法对中文做出正确的分词,假设有如下英文句子:
"Hello world! Hello PHP!"
通过上面提及的方法,可以很简单的把这个句子分词为:
1 Hello
2 world
3 PHP
我们再来看看中文的句子:
"你好世界,你好PHP!"
按照英文的算法,分词如下:
1 你好世界
2 你好PHP
显然是不能满足我们的需要的。
所以,首先我们要做的是,把中文的句子转变为MySQL眼中的英文,以便使得它能以英文分词算法去对句子进行正确的分词处理。
先将上面中文句子进行标点过滤处理,得到以下句子:
你好世界 你好PHP
接着再使用中文分词中较简单实现的二元分词算法对句子进行二元分词,得到以下句子:
你好 好世 世界 你好 PHP
因为把标点符号替换为空格,以及PHP本身为英文字母的关系,可以不用进行二元切分,所以得到上面句子。
这个时候,我们来看看处理过后的句子,会发现,就其书写格式上来说,已经符合英文的书写格式,既以空格,标点来对单词形成自然间隔。只是上面句子没有标点,只有空格而已。
到此,我们已经成功的将中文“翻译”为MySQL能理解的“英文”书写格式。
但是,问题还没解决,首先,MySQL中,ft_min_word_len(分词词汇最小长度)这个参数的默认值为4,也就是4个字母以上长度的单词,才会被考虑,小于4个的,将会被忽略。
如果不改变这个长度,按照上面的分词结果,我们将无法通过 你好,世界,PHP等检索到相关的结果,因为分出来的词太短了,不在MySQL的选择范围内。
我们可以通过修改ft_min_word_len的值,将其设置为2来解决上面问题,但是这样做的话,在检索列表中的原本就为英文的短小词汇,如:PHP,MP3,也会被划入检索范围内,这样做的结果是,出现很多无意义的相关结果。
请看以下列表:
[MP3] the look
[MP3] because of you
因为他们都同有MP3在标题中,所以会出现上述提到的问题。
回到ft_min_word_len值的问题,我们之所以要修改他,是为了能让MySQL找到我们的二元分
相关文档:
InnoDB和MyISAM是在使用MySQL最常用的两个表类型,各有优缺点,视具体应用而定。下面是已知的两者之间的差别,仅供参考。
innodb
InnoDB 给 MySQL 提供了具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID complian ......
不同数据库之间的语法差异还真不少~要崩溃了。
1.创建带自增列临时表:create TEMPORARY table t(id int AUTO_INCREMENT PRIMARY key, u_name varchar(50));--为什么必须要主键?!
向这个临时表中插入数据:insert into t values(null, 'zdy');--为什么一定要加null?!
2.把一张表的查询结果插入临时表:insert into t ......
最近的一个项目在使用C3P0的连接池,数据库为Mysql。开发测试没有问题,在运行中每个一段长的空闲时间就出现异常Communications link failure due to underlying exception:
java 代码
查看了Mysql的文档,以及Connector/J的文档以及在线说明发现,出现这种异常的原因是:
Mysql服务器默认的“wait_timeout&rdquo ......
ALTER [IGNORE] TABLE tbl_name alter_spec [, alter_spec …]
alter_specification:
ADD [COLUMN] create_definition [FIRST | AFTER column_name ]
or ADD INDEX [index_name] (index_col_name,…)
or ADD PRIMARY KEY (index_col_name,&hell ......
最近网站数据量节节攀升,据BD方面通报短期内UV还要上升30%-50%。当前最突出的问题是后台内容审核系统压力太大,已经逐渐力不从心。尽管加了一些硬件但效果并不是太理想,主要还是前一段时间把工作重点都放在前端模块上了。内容管理平台的部分代码没有仔细斟酌。接下来一段时间集中精力优化后台。
首先将多表连查的SQL拿出 ......