第30期:索引设计(全文索引中文处理)

码影漫游家
• 阅读 2404

第30期:索引设计(全文索引中文处理)

本篇是全文索引终篇,来细聊下 MySQL 全文索引对中文如何处理。在了解 MySQL 全文索引如何处理中文之前,先来看看什么是分词。

MySQL 全文索引默认是基于单字节流处理的,也就是按照单词与停止词(默认空格或者标点符号)来划分各个关键词,并且把关键词的文档ID和位置保存到辅助表用于后期检索。这种对英文,数字类的单字节字符处理很好, 比如“I am a boy!”, 每个单词很明确的用空格分割,后期查询只需要按照以空格为分隔符的单词检索就行,这些我前面三篇文章已经详细讲过。但是这种分割方法对多字节字符比如中文不是很友好,对中文来说每个字就是单独的字,无规律的字可以组成词,但是各个词之间不需要按照空格来分割。举个例子:“为中国人自豪” ,这句话包含了三个词“为”,“中国人”,“自豪”。如果按照默认的全文索引处理,搜索其中任何子句,结果肯定是出不来。这也间接导致大家说 MySQL 的全文检索结果不准确,不靠谱,其实并非如此,主要是MySQL 全文索引对分词以及停止符界定有差异。例如下面,表 ft_ch ,有三条记录,怎么查都没有没有结果。

mysql> create table ft_ch(id int unsigned auto_increment primary key, s1 varchar(200),fulltext ft_s1(s1));
Query OK, 0 rows affected (0.39 sec)

mysql> select * from ft_ch where match(s1) against ('我是');
Empty set (0.00 sec)

mysql> select * from ft_ch where match(s1) against ('中国');
Empty set (0.00 sec)

mysql> select * from ft_ch where match(s1) against ('我是中');
Empty set (0.01 sec)

但这张表其实有记录:

mysql> select * from ft_ch;
+----+--------------------------------------+
| id | s1                                   |
+----+--------------------------------------+
|  1 | 我是中国人你是哪里人?               |
|  2 | 我是中国人,你是哪里人?             |
|  3 | 我是中国人 你是哪里人?              |
+----+--------------------------------------+
3 rows in set (0.00 sec)

问题出在哪里呢? 回顾下之前介绍的全文索引,可能就想到了,分词长度不够或者是停止词不对,分词长度见下面参数,停止词默认是空格或者标点符号。

mysql> show variables like '%innodb_ft_%token%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_ft_max_token_size | 84    |
| innodb_ft_min_token_size | 3     |
+--------------------------+-------+
2 rows in set (0.00 sec)

这两个参数定义了最小和最大的分词长度,在此范围内,包含边界的关键词都会被检索出来。之前的查询没有结果的原因就是 SQL 提供的关键词没有触发停止词的边界。 那修改 SQL 里的关键词,再来查询一次,把检索关键词变为 “我是中国人”, 这个关键词刚好后面有一个停止词(空格或者逗号)。

mysql> select * from ft_ch where match(s1) against ('我是中国人');
+----+--------------------------------------+
| id | s1                                   |
+----+--------------------------------------+
|  2 | 我是中国人,你是哪里人?             |
|  3 | 我是中国人 你是哪里人?              |
+----+--------------------------------------+
2 rows in set (0.00 sec)

结果是有了,但是不完整,ID 为 1 的记录没有被查出来。什么原因呢?分词的最小边界是不是太大了? 的确如此,不过调小分词的大小,比如把参数 innodb_ft_min_token_siz e调小到 2 ,那必须得把数据重新录入,类似下面这样:

insert into ft_ch(s1) values ("我是中国人,你是哪里人?");

这数据看起来很怪,按照设置的分词大小,并以空格分割这句话,明显这样数据就乱了,或者说,之后查出来的数据得重新组合处理。显然这样不可行。那 MySQL 有无办法按照国人的思维录入数据,并且还能正常查询出来结果吗?答案是肯定的。

MySQL 从 5.7 就原生提供了处理中文的插件 ngram 来解决这个问题。下面我来介绍下中文处理插件 Ngram .

查看 Ngram 插件是否正常加载, 结果显示为 ON 代表加载成功。

mysql> select * from information_schema.plugins where plugin_name = 'ngram'\G
*************************** 1. row ***************************
           PLUGIN_NAME: ngram
        PLUGIN_VERSION: 0.1
         PLUGIN_STATUS: ACTIVE
           PLUGIN_TYPE: FTPARSER
   PLUGIN_TYPE_VERSION: 1.1
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Oracle Corp
    PLUGIN_DESCRIPTION: Ngram Full-Text Parser
        PLUGIN_LICENSE: GPL
           LOAD_OPTION: ON
1 row in set (0.00 sec)

Ngram 插件只有一个单独的系统参数,那就是配置分词长度,默认为 2 ,也就是 2 个字为一个分词。

mysql> show variables like '%ngram%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| ngram_token_size | 2     |
+------------------+-------+
1 row in set (0.00 sec)

那针对表 ft_ch , 把全文索引由默认改为 Ngram ,只需加上 with parser ngram 子句即可。

mysql> alter table ft_ch drop key ft_s1, add fulltext ft_s1_n( s1) with parser ngram;
Query OK, 0 rows affected (0.35 sec)
Records: 0  Duplicates: 0  Warnings: 0

为了验证 ngram 插件,我再插入一条没有标点符号的记录

mysql> insert into ft_ch(s1) values('我是中国人你是哪里人');
Query OK, 1 row affected (0.01 sec)

接下来再次执行之前的查询,现在有结果了。

mysql>  select * from ft_ch where match(s1) against ('中国');
+----+--------------------------------------+
| id | s1                                   |
+----+--------------------------------------+
|  1 | 我是中国人你是哪里人?               |
|  2 | 我是中国人,你是哪里人?             |
|  3 | 我是中国人 你是哪里人?              |
|  4 | 我是中国人你是哪里人                 |
+----+--------------------------------------+
4 rows in set (0.00 sec)

接下来再看看这些记录到底是怎么分词的,跟默认全文检索分词有什么不一样?针对表 ft_ch ,克隆一张表 ft_en .

mysql> create table ft_en like ft_ch;
Query OK, 0 rows affected (0.40 sec)

mysql> alter table ft_en drop key ft_s1_n, add fulltext ft_s1 (s1);
Query OK, 0 rows affected (0.34 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> insert into ft_en select * from ft_ch;
Query OK, 4 rows affected (0.02 sec)
Records: 4  Duplicates: 0  Warnings: 0

开启监测表ft_en.

mysql> set global innodb_ft_aux_table = 'ytt/ft_en';
Query OK, 0 rows affected (0.00 sec)

查看全文检索缓存表,可以看到分词记录是按照停止词来划分的,其实对中文来说,这样的索引很不完整。

mysql> select word,doc_id,position,doc_count from information_schema.innodb_ft_index_cache;
+--------------------------------+--------+----------+-----------+
| word                           | doc_id | position | doc_count |
+--------------------------------+--------+----------+-----------+
| 你是哪里人                     |      3 |       18 |         2 |
| 你是哪里人                     |      4 |       16 |         2 |
| 我是中国人                     |      3 |        0 |         2 |
| 我是中国人                     |      4 |        0 |         2 |
| 我是中国人你是哪里人           |      2 |        0 |         2 |
| 我是中国人你是哪里人           |      5 |        0 |         2 |
+--------------------------------+--------+----------+-----------+
6 rows in set (0.00 sec)

切换为 ngram 索引表

mysql> set global innodb_ft_aux_table = 'ytt/ft_ch';
Query OK, 0 rows affected (0.00 sec)

查看全文索引缓存表,可以看到分词数据严格按照设定的个数来划分,没有任何冗余数据,也没有按照停止词来分,这点更适合对中文的处理。

mysql> SELECT * FROM INFORMATION_SCHEMA.INNODB_FT_INDEX_CACHE;
+--------+--------------+-------------+-----------+--------+----------+
| WORD   | FIRST_DOC_ID | LAST_DOC_ID | DOC_COUNT | DOC_ID | POSITION |
+--------+--------------+-------------+-----------+--------+----------+
| 中国   |            6 |           6 |         1 |      6 |        6 |
| 人你   |            6 |           6 |         1 |      6 |       12 |
| 你是   |            6 |           6 |         1 |      6 |       15 |
| 哪里   |            6 |           6 |         1 |      6 |       21 |
| 国人   |            6 |           6 |         1 |      6 |        9 |
| 我是   |            6 |           6 |         1 |      6 |        0 |
| 是中   |            6 |           6 |         1 |      6 |        3 |
| 是哪   |            6 |           6 |         1 |      6 |       18 |
| 里人   |            6 |           6 |         1 |      6 |       24 |
+--------+--------------+-------------+-----------+--------+----------+
9 rows in set (0.00 sec)

以上结果还可以发现,标点符号并没有在分词里显示,Ngram 默认把这部分优化掉了(这也就是默认分词为 2 的原因)。

除了分词数据保存方式不同,其他和默认的全文索引没有任何异同。

例如看看内部索引表存储是否类似,查询出来结果和默认的也一样。

mysql> select table_id from information_schema.innodb_tables where name = 'ytt/ft_ch' into @tid;               Query OK, 1 row affected (0.00 sec)

mysql> select table_id,name from information_schema.innodb_tables where name like concat('ytt/fts_',lpad(hex(@tid),16,'0'),'%');
+----------+---------------------------------------------------+
| table_id | name                                              |
+----------+---------------------------------------------------+
|     1431 | ytt/fts_0000000000000596_being_deleted            |
|     1432 | ytt/fts_0000000000000596_being_deleted_cache      |
|     1433 | ytt/fts_0000000000000596_config                   |
|     1434 | ytt/fts_0000000000000596_deleted                  |
|     1435 | ytt/fts_0000000000000596_deleted_cache            |
|     1442 | ytt/fts_0000000000000596_00000000000002be_index_1 |
|     1443 | ytt/fts_0000000000000596_00000000000002be_index_2 |
|     1444 | ytt/fts_0000000000000596_00000000000002be_index_3 |
|     1445 | ytt/fts_0000000000000596_00000000000002be_index_4 |
|     1446 | ytt/fts_0000000000000596_00000000000002be_index_5 |
|     1447 | ytt/fts_0000000000000596_00000000000002be_index_6 |
+----------+---------------------------------------------------+
11 rows in set (0.00 sec)

那把全文所以你变为 ngram 后,只是检索了是否有结果,至于结果是不是正确的,依然没有做校验。为了能更好的说明结果的准确性,我重新插入两行记录:

mysql> truncate ft_ch;
Query OK, 0 rows affected (0.52 sec)

mysql> insert into ft_ch(s1) values('我是中国人,你呢?');
Query OK, 1 row affected (0.02 sec)

mysql> insert into ft_ch(s1) values('我是外国人,你呢?');
Query OK, 1 row affected (0.01 sec)

那接下来看看 ngram 插件对搜索结果的影响。match against 默认是自然语言模式,搜索关键词“中国人”,两行记录都被匹配了出来,但是明显 ID 为 2 的记录不符合检索关键词,为什么 MySQL 把不相干的记录也打印出来? 原因在于,自然语言模式会把搜索关键词按照分词大小做一个并集,也就是说关键词"中国人"被切分为“中国”,“国人”两个关键词,MySQL 用 OR 的方式来输出结果,这样就把包含“中国”或者“国人”的记录全部打印出来, 所以结果有两条!但是这并不是我们预期的结果。

mysql> select * from ft_ch where match(s1) against('中国人' in natural language mode);
+----+-----------------------------+
| id | s1                          |
+----+-----------------------------+
|  1 | 我是中国人,你呢?          |
|  2 | 我是外国人,你呢?          |
+----+-----------------------------+
2 rows in set (0.00 sec)

为了让结果准确无误,就必须用布尔模式,在布尔模式下,只选关键词对应的结果,那下面结果就是对的。

mysql> select * from ft_ch where match(s1) against('中国人' in  boolean mode);
+----+-----------------------------+
| id | s1                          |
+----+-----------------------------+
|  1 | 我是中国人,你呢?          |
+----+-----------------------------+
1 row in set (0.00 sec)

那这时如果想任何结果都能匹配呢?比如,单个词的匹配? 这时布尔模式也得不到想要的结果。 那其实并不是结果不正确,而是分词太大。 这条 SQL 的搜索关键词只有一个字,分词大小默认为 2 ,结果肯定不对。

mysql> select * from ft_ch where match(s1) against('国' in boolean mode);
Empty set (0.01 sec)

此时可以修改分词为 1 ,在配置文件里修改参数 ngram_token_size=1 ;重启 MySQL 服务。

监测表 ft_ch

mysql> set global innodb_ft_aux_table='ytt/ft_ch';
Query OK, 0 rows affected (0.01 sec)

修改分词大小,必须重建索引。 可以看到分词数据把标点符号也包含进去了,这也就是 MySQL 的 ngram 插件分词默认为 2 的原因。

mysql> alter table ft_ch drop key ft_s1_n;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table ft_ch add fulltext ft_s1_n(s1) with parser ngram;
Query OK, 0 rows affected (0.25 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> select * from information_schema.innodb_ft_index_table;
+------+--------------+-------------+-----------+--------+----------+
| WORD | FIRST_DOC_ID | LAST_DOC_ID | DOC_COUNT | DOC_ID | POSITION |
+------+--------------+-------------+-----------+--------+----------+
| ,   |            2 |           3 |         2 |      2 |       15 |
| ,   |            2 |           3 |         2 |      3 |       15 |
| ?   |            2 |           3 |         2 |      2 |       24 |
| ?   |            2 |           3 |         2 |      3 |       24 |
| 中   |            2 |           2 |         1 |      2 |        6 |
| 人   |            2 |           3 |         2 |      2 |       12 |
| 人   |            2 |           3 |         2 |      3 |       12 |
| 你   |            2 |           3 |         2 |      2 |       18 |
| 你   |            2 |           3 |         2 |      3 |       18 |
| 呢   |            2 |           3 |         2 |      2 |       21 |
| 呢   |            2 |           3 |         2 |      3 |       21 |
| 国   |            2 |           3 |         2 |      2 |        9 |
| 国   |            2 |           3 |         2 |      3 |        9 |
| 外   |            3 |           3 |         1 |      3 |        6 |
| 我   |            2 |           3 |         2 |      2 |        0 |
| 我   |            2 |           3 |         2 |      3 |        0 |
| 是   |            2 |           3 |         2 |      2 |        3 |
| 是   |            2 |           3 |         2 |      3 |        3 |
+------+--------------+-------------+-----------+--------+----------+
18 rows in set (0.00 sec)

接下来之前的 SQL 重新执行,结果肯定有了。

mysql> select * from ft_ch where match(s1) against('国' in boolean mode);
+----+-----------------------------+
| id | s1                          |
+----+-----------------------------+
|  1 | 我是中国人,你呢?          |
|  2 | 我是外国人,你呢?          |
+----+-----------------------------+
2 rows in set (0.00 sec)

mysql> select * from ft_ch where match(s1) against('中国人' in boolean mode);
+----+-----------------------------+
| id | s1                          |
+----+-----------------------------+
|  1 | 我是中国人,你呢?          |
+----+-----------------------------+
1 row in set (0.00 sec)

mysql> select * from ft_ch where match(s1) against('人,' in boolean mode);
+----+-----------------------------+
| id | s1                          |
+----+-----------------------------+
|  1 | 我是中国人,你呢?          |
|  2 | 我是外国人,你呢?          |
+----+-----------------------------+
2 rows in set (0.00 sec)

关于 MySQL 的技术内容,你们还有什么想知道的吗?赶紧留言告诉小编吧!

第30期:索引设计(全文索引中文处理)

点赞
收藏
评论区
推荐文章
blmius blmius
4年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
美凌格栋栋酱 美凌格栋栋酱
6个月前
Oracle 分组与拼接字符串同时使用
SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(
Wesley13 Wesley13
3年前
MySQL索引类型
一、简介MySQL目前主要有以下几种索引类型:1.普通索引2.唯一索引3.主键索引4.组合索引5.全文索引二、语句CREATETABLEtable_namecol_namedatatypeunique|fulltextindex|keyindex_name(c
Wesley13 Wesley13
3年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
3年前
InnoDB全文索引:N
InnoDB默认的全文索引parser非常合适于Latin,因为Latin是通过空格来分词的。但对于像中文,日文和韩文来说,没有这样的分隔符。一个词可以由多个字来组成,所以我们需要用不同的方式来处理。在MySQL5.7.6(https://www.oschina.net/action/GoToLink?urlhttp%3A%2F%2Fdev.mysq
Wesley13 Wesley13
3年前
mysql全文索引理解
第一次在工作中使用全文索引,遇到了一些坑,研究了下,写下我的一些理解。mysql5.6后InnoDB存储引擎已经支持全文索引。1、首先创建一张表test2。CREATETABLEtest2 (idINT(11),value2 TEXT )2、给test2的value2字段加上全文索引。ALTERTABLEtes
Wesley13 Wesley13
3年前
MySQL索引背后的数据结构及算法原理
摘要本文以MySQL数据库为研究对象,讨论与数据库索引相关的一些话题。特别需要说明的是,MySQL支持诸多存储引擎,而各种存储引擎对索引的支持也各不相同,因此MySQL数据库支持多种索引类型,如BTree索引,哈希索引,全文索引等等。为了避免混乱,本文将只关注于BTree索引,因为这是平常使用MySQL时主要打交道的索引,至于哈希索引和全文索引本文
Easter79 Easter79
3年前
Sqlserver2008及以上使用全文索引排除干扰词
关于SQLServer2008全文索引干扰词使用SQLSERVER2008全文索引进行搜索contains(Keywords,'"xxofxx\"')(注意是后面有包含"\"号的查询),由于包含了类似"of","and","or"等这类默认的全文索引干扰词,导致查询不到结果。可以按如下方法解决:1.自定自己的干扰词库
Stella981 Stella981
3年前
ELK学习笔记之ElasticSearch的索引详解
0x00ElasticSearch的索引和MySQL的索引方式对比Elasticsearch是通过Lucene的倒排索引技术实现比关系型数据库更快的过滤。特别是它对多条件的过滤支持非常好,比如年龄在18和30之间,性别为女性这样的组合查询。倒排索引很多地方都有介绍,但是其比关系型
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究
一朵云 一朵云
1年前
码影漫游家
码影漫游家
Lv1
浪漫世界值得孤身。
文章
4
粉丝
0
获赞
0