MySQL中InnoDB全文检索

InnoDB存储引擎从1.2.x开始支持全文索引技术,其采用full inverted index的方式。在InnoDB存储引擎中,将(DocumentID,Postition)视为一个ilist。因此在全文检索的表中,有两个列,一个是word字段,一个是ilist字段。并且在word字段上有设索引。此外,由于InnoDB存储引擎在ilist字段上存放了Position信息,故可以进行Proximity Search,而MyISAM不支持该特性

如之前所说,倒排索引需要将word存放在一个表中,这个表称为Auxiliary Table(辅助表)在InnoDB存储引擎中,为了提高全文检索的并发性。共有6张Auxiliary Table,每张表根据word的Latin编码进行分区

Auxiliary Table是持久的表,存放在磁盘上,然而在InnoDB存储引擎的全文索引中,还有另外一个重要的概念FTS Index Cache(全文检索索引缓存),其用来提高全文检索的性能

FTS Index Cache是一个红黑树结构,其根据(word,ilist)进行排序,这意味着插入的数据已更新了对应的表,但是对全文索引的更新可能在粉刺操作后还在FTS Index Cache中,Auxiliary Table可能没有更新。InnoDB存储引擎会批量对Auxiliary Table进行更新.而不是每次插入后更新一次Auxiliary Table.当全文检索进行查询时,Auxiliary Table首先会将在FTS Index Cache 中对应的word字段合并到Auxiliary Table中,然后进行查询。这种merge操作非常类似之前的Insert Buffer功能。不同的是Insert Buffer是个持久性的对象,并且是B+树结构,然后FTS Index Cache的作用又和Insert Buffer类似,它提高了InnoDB存储引擎的性能,并且由于其根据红黑树排序后进行批量插入,其产生的Auxiliary Table相对较小

InnoDB存储引擎允许用户查看指定倒排索引的Auxiliary Table分词的信息,可以通过设置innodb_ft_aux_table来观察倒排索引的Auxiliary Table 下面的SQL 语句设置查看test架构下表fts_a的Auxiliary Table:

SET GLOBAL innodb_ft_aux_table=‘test/fts_a‘;

可以在information_schema架构下的表INNODB_FT_INDEX_TABLE得到表fts_a中的分词信息。

对于InnoDB存储引擎而言,其总是在事务提交时将分词写入到FTS Index Cache,然后通过批量写入到磁盘。虽然InnoDB存储引擎通过一种延时的、批量的写入方式来提高数据库的性能,但是上述操作仅在事务提交时发生。

当数据库关闭时,在FTS Index Cache中的数据库会同步到磁盘上的Auxiliary Table中。如果当数据库发生宕机时,一些FTS Index Cache中的数据可能未同步到磁盘上,那么下次重启数据库时,当用户对表进行全文检索(查询、插入)时,InnoDB存储引擎会自动读取未完成的文档,然后进行分词操作,再将分词结果放到FTS Index Cache

为了支持全文检索,必须有一个列与word进行映射。在InnoDB中这个列被命名成FTS_DOC_ID,其类型为BIGINT UNSIGNED NOT NULL,并且InnoDB存储引擎自动会在该列加上一个名为FTS_DOC_ID_INDEX的Unique Index.这些操作由存储引擎自己完成,用户也可以在建表时自动添加FTS_DOC_ID,以及对应的Unique Index。由于列名FTS_DOC_ID聚友特殊意义,因此在创建时必须注意相应的类型,否则会报错

可以看到,由于用户手动定义FTS_DOC_ID为INT,而非BIGINT因此在创建时候会抛出异常,应该将此处修改成对应的BIGINT即可

文档中的分词的插入操作是在事务提交时完成,但是对于删除操作,其在事务提交时,不删除磁盘Auxiliary Table的记录,而只是删除FTS Cache Index记录,对于Auxiliary Table中被删除的记录,存储引擎会记录其FTS DOCUMENT ID ,并将其保存在DELETE auxiliary table中,在设置参数innodb_ft_aux_table后,用户可以访问information_schema架构下的表INNODB_FT_DELETED来观察删除的FTS Document ID

由于文档的DML操作实际并不删除索引中的数据,相反还会在对应的DELETED表中插入记录,因此随着应用程序的允许,索引会变得越来越大,即使索引中的有些数据已经被删除,查询也不会选择这类记录,为此,InnoDB提供了一种方式,允许用户手工将已删除的记录从索引中彻底删除,这就是OPTIMIZE TABLE。因为OPTIMIZE TABLE还会进行一些其他的操作。如Cardinality重新统计,若用户希望对倒排索引进行操作,可以通过innodb_optimize_fulltext_only设置

SET GLOBAL innodb_optimize_fulltext_only=1;

OPTIMIZE TABLE fts_a;

若被删除的文档很多,那么OPTIMIZE TABLE操作可能占用非常多的时间,会影响到程序并发性,并极大的降低用户的响应时间,用户可以通过参数innodb_ft_num_word_optimize来限制每次实际删除的分词数量,默认为2000

CREATE TABLE fts_a(
FTS_DOC_ID BIGINT UNSIGNED AUTO_INCREMENT NOT NULL,
body TEXT,
PRIMARY KEY(FTS_DOC_ID)
);

INSERT INTO fts_a SELECT NULL,‘pease porridge in the post‘;
INSERT INTO fts_a SELECT NULL,‘pease porridge hot,pease porridge cold‘;
INSERT INTO fts_a SELECT NULL,‘Nine days old‘;
INSERT INTO fts_a SELECT NULL,‘Some like it hot,some like it cold‘;
INSERT INTO fts_a SELECT NULL,‘Some like it the pot‘;
INSERT INTO fts_a SELECT NULL,‘Nine days old‘;
INSERT INTO fts_a SELECT NULL,‘I like code days‘;

CREATE FULLTEXT INDEX idx_fts ON fts_a(body);

查看数据

mysql> select * from fts_a;
+------------+----------------------------------------+
| FTS_DOC_ID | body                                   |
+------------+----------------------------------------+
|          1 | pease porridge in the post             |
|          2 | pease porridge hot,pease porridge cold |
|          3 | Nine days old                          |
|          4 | Some like it hot,some like it cold     |
|          5 | Some like it the pot                   |
|          6 | Nine days old                          |
|          7 | I like code days                       |
+------------+----------------------------------------+
7 rows in set (0.00 sec)
mysql> set global innodb_ft_aux_table=‘iot2/fts_a‘;
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM information_schema.`INNODB_FT_INDEX_TABLE`;
+----------+--------------+-------------+-----------+--------+----------+
| WORD | FIRST_DOC_ID | LAST_DOC_ID | DOC_COUNT | DOC_ID | POSITION |
+----------+--------------+-------------+-----------+--------+----------+
| code | 7 | 7 | 1 | 7 | 7 |
| cold | 2 | 4 | 2 | 2 | 34 |
| cold | 2 | 4 | 2 | 4 | 30 |
| days | 3 | 7 | 3 | 3 | 5 |
| days | 3 | 7 | 3 | 6 | 5 |
| days | 3 | 7 | 3 | 7 | 12 |
| hot | 2 | 4 | 2 | 2 | 15 |
| hot | 2 | 4 | 2 | 4 | 13 |
| like | 4 | 7 | 3 | 4 | 5 |
| like | 4 | 7 | 3 | 4 | 17 |
| like | 4 | 7 | 3 | 5 | 5 |
| like | 4 | 7 | 3 | 7 | 2 |
| nine | 3 | 6 | 2 | 3 | 0 |
| nine | 3 | 6 | 2 | 6 | 0 |
| old | 3 | 6 | 2 | 3 | 10 |
| old | 3 | 6 | 2 | 6 | 10 |
| pease | 1 | 2 | 2 | 1 | 0 |
| pease | 1 | 2 | 2 | 2 | 0 |
| pease | 1 | 2 | 2 | 2 | 19 |
| porridge | 1 | 2 | 2 | 1 | 6 |
| porridge | 1 | 2 | 2 | 2 | 6 |
| porridge | 1 | 2 | 2 | 2 | 19 |
| post | 1 | 1 | 1 | 1 | 22 |
| pot | 5 | 5 | 1 | 5 | 17 |
| some | 4 | 5 | 2 | 4 | 0 |
| some | 4 | 5 | 2 | 4 | 17 |
| some | 4 | 5 | 2 | 5 | 0 |
+----------+--------------+-------------+-----------+--------+----------+
27 rows in set (0.00 sec)

可以看到每个word对应一个DOC_ID和POSITION。此外,还记录了FIRST_DOC_ID、LAST_DOC_ID、DOC_COUNT分别代表该word第一次出现文档的ID,最后一次出现的文档ID,以及该word在多少个文档中存在。

若此时执行下面的SQL语句,会删除FTS_DOC_ID为7的文档

DELETE FROM fts_a WHERE FTS_DOC_ID=7;

InnoDB存储引擎并不会直接删除索引中对应的记录,而是将删除的文档ID插入到DELETED表

SELECT * FROM information_schema.`INNODB_FT_DELETED`;

如果用户想要彻底删除倒排索引中该文档的分词信息,可以

mysql> SET GLOBAL innodb_optimize_fulltext_only=1;
Query OK, 0 rows affected (0.00 sec)

mysql> OPTIMIZE TABLE fts_a;
+------------+----------+----------+----------+
| Table      | Op       | Msg_type | Msg_text |
+------------+----------+----------+----------+
| iot2.fts_a | optimize | status   | OK       |
+------------+----------+----------+----------+
1 row in set (0.08 sec)

mysql> SELECT * FROM information_schema.`INNODB_FT_DELETED`;
+--------+
| DOC_ID |
+--------+
|      7 |
+--------+
1 row in set (0.00 sec)

mysql> SELECT * FROM information_schema.`INNODB_FT_BEING_DELETED`;
+--------+
| DOC_ID |
+--------+
|      7 |
+--------+
1 row in set (0.00 sec)

运行OPTIMIZE TABLE 可以将记录彻底删除,并且彻底删除的文档ID会记录到INNODB_FT_BEGIN_DELETED中。此外,由于7这个文档一倍删除,因此不允许在插入这个文档ID,否则会抛出异常

mysql> INSERT INTO fts_a SELECT 7,‘I like this days‘;
ERROR 182 (HY000): Invalid InnoDB FTS Doc ID

stopword列表(stopword list)是本节最后阐述的一个概念,其表示该列表中的word不需要对其进行索引分词操作。例如,对于the这个单词,由于其不具有具体的意义,因此将其视为stopword,InnoDB存储引擎有一张默认的stopword列表,在information_schema架构下,表名为INNODB_FT_DEFAULT_STOPWORD,默认为36个stopword可以通过参数innodb_ft_server_stopword_table来定义stopword列表,如

mysql> CREATE TABLE innodb_ft_bug (
    ->   value VARCHAR(18) NOT NULL DEFAULT ‘‘
    -> ) ENGINE=INNODB DEFAULT CHARSET=utf8;  #此处必须为utf8不然会碰到bug
Query OK, 0 rows affected (0.07 sec)

mysql> SET GLOBAL innodb_ft_server_stopword_table=‘iot2/innodb_ft_bug‘;
Query OK, 0 rows affected (0.00 sec)

遇到bug的情形

mysql> CREATE TABLE user_stopword(VALUE VARCHAR(30))ENGINE=INNODB;
Query OK, 0 rows affected (0.03 sec)
mysql> SET GLOBAL innodb_ft_server_stopword_table=‘iot2/user_stopword‘;
ERROR 1231 (42000): Variable ‘innodb_ft_server_stopword_table‘ can‘t be set to the value of ‘iot2/user_stopword‘

观察错误日志提示

InnoDB: invalid column name for stopword table iot2/user_stopword. Its first column must be named as ‘value‘.

 

使用全文检索还有以下限制

每张表只能有一个全文检索的索引

由多列组合而成的全文检索的索引必须使用相同的字符集与排序规则

不支持没有单词界定符delimiter的语言,如中文 日文汉语等

时间: 2024-10-10 10:15:37

MySQL中InnoDB全文检索的相关文章

mysql中InnoDB存储引擎的行锁和表锁

Mysql的InnoDB存储引擎支持事务,默认是行锁.因为这个特性,所以数据库支持高并发,但是如果InnoDB更新数据的时候不是行锁,而是表锁的话,那么其并发性会大打折扣,而且也可能导致你的程序出错. 而导致行锁变为表锁的情况之一就是: SQL的更新(update)或者删除(delete)语句中未使用到索引,导致在InnoDB在对数据进行相应操作的时候必须把整个表锁起来进行检索(表锁).而如果使用了索引的话,InnoDB只会通过索引条件检索数据,而只锁住索引对应的行(行锁). 下面记录一下我遇到

MySQL中innodb引擎分析(初始化)

MySQL的存储引擎是以插件形式工作的,这应该是MySQL的一大特色了吧! 依据<深入理解MySQL>的内容,5.1版本号时存储引擎的插件化都还不是彻底,确切的说是刚加入的特性.为MySQL加入一个存储引擎时,须要更改一些上层代码,零散的更改本来就有点麻烦,同一时候project也要又一次编译一次.我听别人说,已经能够不改C/C++代码就直接加入引擎了.这种话,折腾存储引擎的话就更方便了! 这段代码来自ha_innodb.cc,这是MySQL中申明存储引擎插件的标准过程.这段代码利用了宏.在p

MYSQL中InnoDB特性浅谈

许久没有更新博客,上周末放假把网易大牛姜sir的著作MYSQL技术内幕InnoDB存储引擎又翻阅了一番,对当前工作的InnoDB特性有了一些新的认识,下面谈谈自己的读后感. 1. InnoDB的体系架构由一系列后台线程,内存池和文件组成,这点与其他DB有相似之处. 在内存中划分了一块区域,即缓冲池,用来临时存放用户读写的数据页. InnoDB上对缓冲池读写数据页,刷新到磁盘等操作也使用了CHECKPOINT机制,LRU算法,这点与SQLSERVER,DB2等数据库设计一致,这里不再阐述.需要注意

mysql中InnoDB表为什么要建议用自增列做主键

InnoDB引擎表的特点 1.InnoDB引擎表是基于B+树的索引组织表(IOT) 关于B+树 (图片来源于网上) B+ 树的特点: (1)所有关键字都出现在叶子结点的链表中(稠密索引),且链表中的关键字恰好是有序的; (2)不可能在非叶子结点命中; (3)非叶子结点相当于是叶子结点的索引(稀疏索引),叶子结点相当于是存储(关键字)数据的数据层; 2.如果我们定义了主键(PRIMARY KEY),那么InnoDB会选择主键作为聚集索引.如果没有显式定义主键,则InnoDB会选择第一个不包含有NU

mysql中innodb和myisam的区别

InnoDB和MyISAM是很多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,5.7之后就不一样了 1.事务和外键InnoDB具有事务,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID.如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能MyISAM管理非事务表.它提供高速存储和检索,以及全文搜索能力.如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择2.FULLTEXTInnodb不支持全文索

MySQL中InnoDB脏页刷新机制Checkpoint

我们知道InnoDB采用Write Ahead Log策略来防止宕机数据丢失,即事务提交时,先写重做日志,再修改内存数据页,这样就产生了脏页.既然有重做日志保证数据持久性,查询时也可以直接从缓冲池页中取数据,那为什么还要刷新脏页到磁盘呢?如果重做日志可以无限增大,同时缓冲池足够大,能够缓存所有数据,那么是不需要将缓冲池中的脏页刷新到磁盘.但是,通常会有以下几个问题: 服务器内存有限,缓冲池不够用,无法缓存全部数据 重做日志无限增大成本要求太高 宕机时如果重做全部日志恢复时间过长 事实上,当数据库

Mysql中innodb和myisam

innodb和myisam两种存储引擎的区别 1.事务和外键 1)InnoDB具有事务,支持4个事务隔离级别,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID.如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能 2)MyISAM管理非事务表.它提供高速存储和检索,以及全文搜索能力.如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择 2.全文索引 1)Innodb不支持全文索引,如果一定要用的话,最好使用sph

mysql中innodb和myisam对比及索引原理区别(转)

InnoDB和MyISAM是很多人在使用MySQL时最常用的两个表类型,这两个表类型各有优劣,5.7之后就不一样了 1.事务和外键 InnoDB具有事务,支持4个事务隔离级别,回滚,崩溃修复能力和多版本并发的事务安全,包括ACID.如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能 MyISAM管理非事务表.它提供高速存储和检索,以及全文搜索能力.如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择 2.全文索引 I

MySQL中Innodb的聚簇索引和非聚簇索引

聚簇索引 数据库表的索引从数据存储方式上可以分为聚簇索引和非聚簇索引(又叫二级索引)两种.Innodb的聚簇索引在同一个B-Tree中保存了索引列和具体的数据,在聚簇索引中,实际的数据保存在叶子页中,中间的节点页保存指向下一层页面的指针.“聚簇”的意思是数据行被按照一定顺序一个个紧密地排列在一起存储.一个表只能有一个聚簇索引,因为在一个表中数据的存放方式只有一种. 一般来说,将通过主键作为聚簇索引的索引列,也就是通过主键聚集数据.下图展示了Innodb中聚簇索引的结构(图片来自<高性能MySQL